Commit 37528c0
authored
fix: testing ci (#1171)
<!-- greptile_comment -->
<h3>Greptile Summary</h3>
This PR adds a new CI parity-check script (`check-parity.ts`) that runs
both the Vite compiler and the `gt generate` CLI, then compares their
JSON manifests entry-by-entry, skipping Derive/Static entries that are
intentionally excluded from compiler extraction. The comparison logic,
Derive detection, and exit-code handling all look correct.
<details open><summary><h3>Confidence Score: 5/5</h3></summary>
Safe to merge; all findings are minor style suggestions that do not
affect correctness in typical CI environments.
The core comparison logic, Derive filtering, and exit-code handling are
all correct. The two flagged items (unquoted path and missing pre-flight
guard) are P2 quality improvements — CI paths rarely contain spaces, and
the existing manifest-existence checks already catch most
misconfiguration scenarios.
No files require special attention.
</details>
<details><summary><h3>Important Files Changed</h3></summary>
| Filename | Overview |
|----------|----------|
| tests/apps/compiler-cli-parity/scripts/check-parity.ts | New CI
parity-check script that runs vite build and gt generate, then compares
their JSON manifests key-by-key with Derive-entry filtering; minor
path-quoting and missing pre-flight guard issues noted. |
</details>
</details>
<details><summary><h3>Flowchart</h3></summary>
```mermaid
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Start: check-parity.ts] --> B[Clean previous outputs]
B --> C[pnpm vite build]
C --> D{COMPILER_MANIFEST exists?}
D -- No --> E[console.error + exit 1]
D -- Yes --> F[node cli/dist/main.js generate]
F --> G{CLI_MANIFEST exists?}
G -- No --> E
G -- Yes --> H[Load both JSON manifests]
H --> I[Build allHashes union set]
I --> J{For each hash}
J -- both present --> K{containsDerive?}
K -- Yes --> L[skippedDerive++]
K -- No --> M{deepEqual?}
M -- Yes --> N[matched++]
M -- No --> O[mismatched++ / push mismatch]
J -- compiler only --> P{containsDerive?}
P -- Yes --> L
P -- No --> Q[compilerOnly++ / push mismatch]
J -- CLI only --> R{containsDerive?}
R -- Yes --> L
R -- No --> S[cliOnly++ / push mismatch]
L & N & O & Q & S --> T{more hashes?}
T -- Yes --> J
T -- No --> U{mismatches.length > 0?}
U -- Yes --> V[Print mismatches + exit 1]
U -- No --> W{matched === 0?}
W -- Yes --> X[Print warning + exit 1]
W -- No --> Y[Print success + exit 0]
```
</details>
<!-- greptile_failed_comments -->
<details open><summary><h3>Comments Outside Diff (1)</h3></summary>
1. `tests/apps/compiler-cli-parity/scripts/check-parity.ts`, line 68-78
([link](https://github.com/generaltranslation/gt/blob/24a511b995d207c0ab2062161ad8ab6b6636802e/tests/apps/compiler-cli-parity/scripts/check-parity.ts#L68-L78))
<a href="#"><img alt="P1"
src="https://greptile-static-assets.s3.amazonaws.com/badges/p1.svg?v=7"
align="top"></a> **Array vs plain-object conflation in `deepEqual`**
When one operand is an `Array` and the other is a plain object, both
pass the `typeof value === 'object'` guard, so the function falls
through to the object-key comparison branch instead of returning
`false`. This means `deepEqual([1, 2], { 0: 1, 1: 2 })` returns `true`,
which is wrong. A guard is needed before the object branch.
<details><summary>Prompt To Fix With AI</summary>
`````markdown
This is a comment left during a code review.
Path: tests/apps/compiler-cli-parity/scripts/check-parity.ts
Line: 68-78
Comment:
**Array vs plain-object conflation in `deepEqual`**
When one operand is an `Array` and the other is a plain object, both
pass the `typeof value === 'object'` guard, so the function falls
through to the object-key comparison branch instead of returning
`false`. This means `deepEqual([1, 2], { 0: 1, 1: 2 })` returns `true`,
which is wrong. A guard is needed before the object branch.
How can I resolve this? If you propose a fix, please make it concise.
`````
</details>
</details>
<!-- /greptile_failed_comments -->
<details><summary>Prompt To Fix All With AI</summary>
`````markdown
This is a comment left during a code review.
Path: tests/apps/compiler-cli-parity/scripts/check-parity.ts
Line: 99
Comment:
**Unquoted path in shell command**
`gtMain` is interpolated directly into the shell command string without quoting. If `MONOREPO_ROOT` (resolved via three `..` hops from `__dirname`) ever contains spaces, `node` will receive a split path and fail with a confusing "module not found" error.
```suggestion
execSync(`node "${gtMain}" generate`, { cwd: ROOT, stdio: 'inherit' });
```
How can I resolve this? If you propose a fix, please make it concise.
---
This is a comment left during a code review.
Path: tests/apps/compiler-cli-parity/scripts/check-parity.ts
Line: 99
Comment:
**Missing pre-flight check for CLI binary**
`gtMain` is used directly without checking whether the file exists. If the `cli` package hasn't been built yet (i.e. `dist/main.js` is absent), the error from Node will say "Cannot find module …" rather than something actionable. A short guard here would save debugging time in CI.
```suggestion
if (!fs.existsSync(gtMain)) {
console.error('ERROR: CLI dist not found at', gtMain, '— run `pnpm
build` in the cli package first.');
process.exit(1);
}
execSync(`node "${gtMain}" generate`, { cwd: ROOT, stdio: 'inherit' });
```
How can I resolve this? If you propose a fix, please make it concise.
`````
</details>
<sub>Reviews (2): Last reviewed commit: ["address github sec
issue"](6c1a63f)
| [Re-trigger
Greptile](https://app.greptile.com/api/retrigger?id=27334546)</sub>
<!-- /greptile_comment -->1 parent 5b85ccd commit 37528c0
1 file changed
+5
-3
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
5 | 5 | | |
6 | 6 | | |
7 | 7 | | |
8 | | - | |
| 8 | + | |
9 | 9 | | |
10 | 10 | | |
11 | 11 | | |
12 | | - | |
| 12 | + | |
13 | 13 | | |
14 | 14 | | |
15 | 15 | | |
| |||
94 | 94 | | |
95 | 95 | | |
96 | 96 | | |
97 | | - | |
| 97 | + | |
| 98 | + | |
| 99 | + | |
98 | 100 | | |
99 | 101 | | |
100 | 102 | | |
| |||
0 commit comments