es-x-node-support-update

name

es-x-node-support-update

description

Update eslint-plugin-es-x Node.js support in its own dedicated PR. Use during major release preparation or support policy changes to check the current Node.js release schedule, keep the intended non-EOL Node.js lines with explicit major-line ranges, and update package engines, public documentation requirements, Node.js CI matrix entries, lockfile root metadata, release notes, and verification without changing the ESLint peer dependency.

ES-X Node.js Support Update

Workflow

Use this when dropping old Node.js support. Keep this work separate from ESLint support drops and annual ECMAScript snapshot config updates unless the user explicitly asks for a combined PR.

1. Inspect current Node.js support declarations:
   • package.json engines.node
   • docs/index.md Requirements Node.js line
   • .github/workflows/ci.yml Node.js matrix entries
   • top-level package-lock.json engines.node
2. Check current Node.js EOL status and releases before choosing the new support range:
   • Prefer the official schedule data at https://raw.githubusercontent.com/nodejs/Release/main/schedule.json.
   • Use the current date to exclude Node.js majors whose end date has passed.
   • Use official release data, such as https://nodejs.org/dist/index.json, to find the latest release for each retained non-EOL major.
   • Include Current and LTS Node.js majors when they are not EOL; do not restrict the choice to LTS unless the user explicitly asks.
3. Choose the non-EOL Node.js major lines that should remain supported after the drop, then build package.json engines.node from those lines:
   • For each retained line except the newest retained major, use a caret range from the first patch release of that line's latest required major/minor line, such as ^22.18.0.
   • For the newest retained major, use an open lower-bound range from the first patch release of that line's latest required major/minor line, such as >=24.7.0.
   • Join multiple ranges with ||. For example, if Node.js 22 and 24 remain supported, use a range shaped like ^22.18.0 || >=24.7.0, not >=22.18.0.
   • Do not add any other upper bound unless the project already has one or the user explicitly asks for one.
4. Update CI:
   • Remove jobs for Node.js majors and minor lines outside the new supported range, even if those older majors are not EOL.
   • Keep one minimum-supported Node.js job for each retained major line, such as 22.18.0 and 24.7.0 when the new range is ^22.18.0 || >=24.7.0.
   • Keep platform coverage on a normal supported Node.js version.
   • Do not change ESLint matrix versions except where a Node.js job must be moved to a supported Node.js version.
5. Update user-facing support documentation:
   • Keep docs/index.md Requirements in sync with package.json engines.node.
   • Preserve the existing prose format: - Node.js `X.Y.Z`, `A.B.C` or newer..
   • For multiple supported Node.js ranges, list the lower-bound version from each range rather than pasting the raw semver expression.
6. Refresh lockfile root metadata with npm install --package-lock-only if package-lock.json does not update automatically.
7. Add release notes through .agents/es-x-changeset/SKILL.md.
8. Verify through .agents/es-x-release-verification/SKILL.md.

Current Major-Prep Pattern

For any major-prep Node.js support PR:

• Check the official Node.js release schedule and release index.
• Build the engine range from the retained non-EOL Node.js lines. Use caret ranges for retained older majors and an open lower-bound range for the newest retained major, such as ^22.18.0 || >=24.7.0.
• Keep docs/index.md Requirements synchronized with the same minimum versions while preserving its prose format.
• Remove CI coverage for Node.js versions outside that range.
• Keep the ESLint support range unchanged in this PR.