fix(web): declare a Node floor the lint toolchain can actually run on - #1913
ChiragAgg5k wants to merge 1 commit into
Conversation
The Web and React Native templates promise `"node": ">=18.0.0"` while pulling `@eslint/js` 10.0.1 and `eslint` 10.10.0, which declare `^20.19.0 || ^22.13.0 || >=24`. A contributor on the Node version the package advertises gets engine warnings, fails `npm ci` under `engine-strict`, and cannot run `npm run lint` at all. The floor now matches what those dependencies accept. Narrowing it costs nothing real: Node 18 reached end of life in April 2025 and 20.19 is the lowest version eslint 10 runs on, so this is the smallest range that makes the declaration true. The alternative — holding lint tooling back to a release that still supports an EOL Node — trades a live toolchain for a promise nobody is keeping. Only these two templates declare `engines`; the Node template pulls the same eslint 10 without one, so it is unaffected.
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| }, | ||
| "engines": { | ||
| "node": ">=18.0.0" | ||
| "node": "^20.19.0 || ^22.13.0 || >=24" |
There was a problem hiding this comment.
These templates produce published SDK packages, so engines.node constrains downstream consumers as well as contributors. A consumer using the still-documented Node 18 runtime with engine-strict will now have installation rejected, even though the incompatible ESLint packages are development-only and absent from consumer installs. The same change appears in templates/react-native/package.json.twig:37, where Node 18 is also still documented as supported.
Prompt To Fix With AI
This is a comment left during a code review.
Path: templates/web/package.json.twig
Line: 37
Comment:
**Consumer Node Support Regresses**
These templates produce published SDK packages, so `engines.node` constrains downstream consumers as well as contributors. A consumer using the still-documented Node 18 runtime with `engine-strict` will now have installation rejected, even though the incompatible ESLint packages are development-only and absent from consumer installs. The same change appears in `templates/react-native/package.json.twig:37`, where Node 18 is also still documented as supported.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
| }, | ||
| "engines": { | ||
| "node": ">=18.0.0" | ||
| "node": "^20.19.0 || ^22.13.0 || >=24" |
There was a problem hiding this comment.
The matching Web package-lock template still records the root package engine as >=18.0.0, while this generated package manifest now requires ^20.19.0 || ^22.13.0 || >=24. The React Native templates have the same mismatch. Newly generated repositories will therefore contain contradictory Node requirements, and routine lockfile regeneration may produce unexplained repository changes.
Prompt To Fix With AI
This is a comment left during a code review.
Path: templates/web/package.json.twig
Line: 37
Comment:
**Generated Engine Metadata Conflicts**
The matching Web package-lock template still records the root package engine as `>=18.0.0`, while this generated package manifest now requires `^20.19.0 || ^22.13.0 || >=24`. The React Native templates have the same mismatch. Newly generated repositories will therefore contain contradictory Node requirements, and routine lockfile regeneration may produce unexplained repository changes.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
|
Closing this — not worth the trade. The mismatch is real but contributor-facing only: npm does not apply devDependency engines to anyone installing a generated SDK, so nothing reaches consumers. Raising If this is picked up again, the version that does not touch the consumer contract is holding the lint dependencies at a release that still runs on the advertised floor, rather than moving the floor to match the tooling. |
1 participant
The Web and React Native templates declare
"node": ">=18.0.0"inengineswhile theirdevDependenciespull@eslint/js10.0.1 andeslint10.10.0, both of which declare"node": "^20.19.0 || ^22.13.0 || >=24". Every SDK generated from those templates inherits the contradiction.What it costs a contributor working on a generated SDK repo at the advertised Node version: engine warnings on install, a hard failure under
engine-strict, and no way to runnpm run lintornpm run lint:fixat all. Consumers are unaffected — npm does not apply devDependency engines to installers of a package — so this is a contributor-facing inconsistency rather than a runtime one.The fix
engines.nodebecomes^20.19.0 || ^22.13.0 || >=24in both templates, matching what the lint toolchain accepts.The other direction would be to hold eslint at a release that still supports Node 18. That trades a current toolchain for a promise nobody is keeping: Node 18 reached end of life in April 2025, and 20.19 is the lowest version eslint 10 will run on. This is the smallest range that makes the declaration true.
Only these two templates declare
engines. The Node template pulls the same eslint 10 without one, so nothing there changes.Verification
Generated the Console Web SDK against a patched generator and parsed the result: valid JSON,
enginesrenders as{"node": "^20.19.0 || ^22.13.0 || >=24"}, and the rest of the package — including theimpersonateuseridURL builders restored in #1912 — is byte-identical to a stock 5.0.2 generation.Found by Greptile on appwrite/sdk-for-console#112, where the mismatch first shipped into a generated SDK. That PR is the 16.1.0 Console release; it is not blocked on this, so the corrected
engineswill land in whichever release follows.