🚀 version changed packages

[npayfebot]

Releases

@naverpay/eslint-config@2.4.2

Patch Changes

• 910fa9d: Update typescript-eslint for TypeScript 6.0 support

[yongsk0066]

claude 리뷰가 뭔가 오래 pending 상태이네요. 🤔

배포해보겠습니다

[2-one-week]

돈이 없어서..그럴걸요? ㅋㅋㅋㅋ

[claude]

🔴 The typescript-eslint upgrade from ^8.34.0 to ^8.58.0 silently drops Node.js compatibility for Node 18.x, Node 20.9-20.18, and Node 21.x via a transitive dependency. @typescript-eslint/visitor-keys@8.58.0 itself still declares engines node ^18.18.0 || ^20.9.0 || >=21.1.0, masking the stricter requirement from its transitive dep eslint-visitor-keys@5.0.1 which requires node ^20.19.0 || ^22.13.0 || >=24. Since this is shipped as a patch release (2.4.1 to 2.4.2), users on affected Node versions will hit unexpected failures with no indication from the changelog.

Extended reasoning...

Transitive Node.js Engine Incompatibility

What the bug is: The PR bumps typescript-eslint from ^8.34.0 to ^8.58.0 as part of a patch release (2.4.1 to 2.4.2). While @typescript-eslint/visitor-keys@8.58.0 continues to advertise engines node ^18.18.0 || ^20.9.0 || >=21.1.0, it now depends on eslint-visitor-keys@5.0.1, whose engine requirement is dramatically stricter: node ^20.19.0 || ^22.13.0 || >=24.

The specific code path that triggers it: The full dependency chain is typescript-eslint@8.58.0 -> @typescript-eslint/visitor-keys@8.58.0 -> eslint-visitor-keys@5.0.1. The previous chain was typescript-eslint@8.34.0 -> @typescript-eslint/visitor-keys@8.34.0 -> eslint-visitor-keys@4.2.0, which had engines ^18.18.0 || ^20.9.0 || >=21.1.0. Both facts are confirmed in the pnpm-lock.yaml snapshots and packages sections.

Why existing code does not prevent it: The package has no engines field in its own package.json, so there is no top-level declaration that could warn users before installation. The intermediate package @typescript-eslint/visitor-keys@8.58.0 still claims broad Node.js support in its own engines field, masking the real constraint imposed by its transitive dependency. Package managers only enforce engines on directly declared dependencies by default; the stricter transitive requirement goes unnoticed until runtime.

What the impact would be: The eslint-visitor-keys@5.0.1 engine pattern (^20.19.0 || ^22.13.0 || >=24) precisely matches the Node.js versions that gained native require(ESM) support (backported to 20.19 and 22.13). This strongly suggests the package switched to ESM, meaning users on Node 18.x or Node 20.9.0-20.18.x will likely encounter hard ERR_REQUIRE_ESM failures at runtime. With pnpm (which enforces engine constraints by default), users may fail at install time.

Step-by-step proof:

1. User is on Node 20.15.0 (within Node 20 LTS, explicitly supported by typescript-eslint's own engines claim).
2. User upgrades @naverpay/eslint-config from 2.4.1 to 2.4.2 (a patch release, no breaking changes expected).
3. pnpm resolves typescript-eslint@8.58.0 -> @typescript-eslint/visitor-keys@8.58.0 -> eslint-visitor-keys@5.0.1.
4. pnpm sees eslint-visitor-keys@5.0.1 requires node ^20.19.0 || ^22.13.0 || >=24, but the running Node is 20.15.0, installation fails or emits an unsatisfied engines warning.
5. Even if the user forces through install, at runtime the ESLint config loads eslint-visitor-keys@5.0.1 which may use ESM-only Node APIs unavailable before 20.19, causing ERR_REQUIRE_ESM or similar crashes.
6. The CHANGELOG entry only says Update typescript-eslint for TypeScript 6.0 support with no mention of any Node.js compatibility change.

How to fix it: Either pin typescript-eslint to a version that retains eslint-visitor-keys@4.x (e.g. ^8.34.0), or add an explicit engines field to packages/eslint-config/package.json so consumers are warned before installation. The CHANGELOG should also document this Node.js compatibility change.

[yongholeeme]

$ show me the money