feat!: Require Node.js ^18.18.0 || ^20.9.0 || >=21.1.0

[mdjermanovic]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[x] Add something to the core
[ ] Other, please explain:

Fixes #17595

What changes did you make? (Give an overview)

Updated package.json to require:

"node": "^18.18.0 || ^20.9.0 || >=21.1.0"

This drops support for Node.js 12/14/16/17/19.

Is there anything you'd like reviewers to focus on?

Did I miss any places that should be updated?

[netlify]

✅ Deploy Preview for docs-eslint ready!

Name	Link
🔨 Latest commit	0929225
🔍 Latest deploy log	https://app.netlify.com/sites/docs-eslint/deploys/65511f0dc373e100083ffcd4
😎 Deploy Preview	https://deploy-preview-17725--docs-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[mdjermanovic]

This is ready for review.

[ota-meshi]

What do you think about using Intl.Segmenter instead of graphemer package?

#17595 (comment)

[mdjermanovic]

What do you think about using Intl.Segmenter instead of graphemer package?

#17595 (comment)

Makes sense to me, though I'm not sure if we should make changes to the key-spacing rule since it's now deprecated.

Would it be 100% functionally equivalent?

[ota-meshi]

I think it is better to reduce the number of dependency packages even if the rules that affect them are deprecated, since it is beneficial for ESLint to reduce the number of dependency packages. What do you think?

Would it be 100% functionally equivalent?

Hmm. It seems that they are not 100% equivalent.
However, I think the purpose of both is the same. I think it would be accepted as a minor breaking change in a major version update, what do you think?

[nzakas]

Let's spin off the Intl.Segmenter discussion into a separate issue so we can continue discussing.

[kibertoad]

why not 18.x?

[mdjermanovic]

There are both 18.x and 18.18.0.

18.x to test on the latest version of Node.js 18 (currently 18.18.2).
18.18.0 to test on the minimum supported version

[mdjermanovic]

Let's spin off the Intl.Segmenter discussion into a separate issue so we can continue discussing.

Agreed. @ota-meshi would you like to open an issue to discuss replacing graphemer with Intl.segmenter?

[ota-meshi]

Agreed. @ota-meshi would you like to open an issue to discuss replacing graphemer with Intl.segmenter?

I'll do it later when I have time.
If possible, I would like to investigate and show what kind of characters there are differences.

[github-actions]

Hi everyone, it looks like we lost track of this pull request. Please review and see what the next steps are. This pull request will auto-close in 7 days without an update.

[aladdin-add]

I noticed several things can be updated:

• eslint/lib/config/flat-config-schema.js

  Lines 12 to 16 in 0dd9704

  	/*
  	* Note: This can be removed in ESLint v9 because structuredClone is available globally
  	* starting in Node.js v17.
  	*/
  	const structuredClone = require("@ungap/structured-clone").default;

• eslint/lib/eslint/flat-eslint.js

  Lines 12 to 13 in 0dd9704

  	// Note: Node.js 12 does not support fs/promises.
  	const fs = require("fs").promises;

sure, it's not a blocker of merging this one, we can update it in another PR later.

[mdjermanovic]

I noticed several things can be updated:

• eslint/lib/config/flat-config-schema.js

  Lines 12 to 16 in 0dd9704

  	/*
  	* Note: This can be removed in ESLint v9 because structuredClone is available globally
  	* starting in Node.js v17.
  	*/
  	const structuredClone = require("@ungap/structured-clone").default;

• eslint/lib/eslint/flat-eslint.js

  Lines 12 to 13 in 0dd9704

  	// Note: Node.js 12 does not support fs/promises.
  	const fs = require("fs").promises;

sure, it's not a blocker of merging this one, we can update it in another PR later.

Good catches! I agree, seems best to merge this PR as-is as a starting point when we start with v9 next week, and then make individual changes like these ones and #17835 in separate PRs so that it will be easier to revisit them separately (and revert if needed; hopefully not) later.