Upgrade to support eslint@v9

[phun-ky]

• chore!: Upgrade to , and update eslint setup

What's cooking:

• Use typescript
• Update lint config
• use node native test runner
• use rollup
• upgraded to eslint v9
• got linting to run

Missing:

• Get tests to run/update tests
• Add generated documentation with typedoc

✅ Closes: #947 #1015 #1083

[changeset-bot]

⚠️ No Changeset found

Latest commit: 926cfe9

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

Stale pull request

[Mettbrot]

@phun-ky can you take this up again? What is missing to get eslint upgraded?

[phun-ky]

@Mettbrot I can take a look at it tomorrow and see if there's anything I can do more. I have some spare time moving forwards apaprently

[Mettbrot]

Wow, cool Thanks! We’d need to find a maintainer of this, it seems pretty silent around the PRs #1107

[phun-ky]

@JounQin first blocker: prettier-eslint-cli uses "eslint": "^8.51.0", as a dep, and also "@prettier/eslint": "npm:prettier-eslint@^16.1.0" as a dep, and that dep uses "eslint": "^8.7.0", as a dep. I have updated to latest, but none of them can be used until they are fixed.

[Mettbrot]

They live in this very repository too, right? Can we update them too and release them in one go?

[JounQin]

overrides for npm/pnpm and resolutions for yarn could be used?

[phun-ky]

hm, I think I've looked at this wrongly. The error I get is from v9: Error: This method cannot be used with flat config. Add your entries directly into the config array. Because the class Linter is used, and the input it expects is the old config. Which I find very odd tbh. I'm trying to find decent enough migration documentation with usage of the Linter in v9, with no luck atm

[phun-ky]

I've posted this in the eslint discord:

I have an issue with migrating prettier-eslint to eslint@v9. prettier-eslint uses the Linter , and for some obscure reasoning, I am not allowed to pass in a flat config (which is the new config in v9) into it, since assertEslintrcConfig is run , and it throws an error telling me that flat configs are not allowed.. Isn't every usage of eslint v9 requiring a flat config?

[phun-ky]

I'm getting a bit closer. Latest update: converted to ts, added rollup. The things that remains: decide if we need to find a getRules equivalent: https://eslint.org/docs/latest/use/migrate-to-9.0.0#-linter-now-expects-flat-config-format, or to only use the rules passed in the options, and to get the linting and tests to run. Please feel free to work on this PR @JounQin

[phun-ky]

Updated description to this PR. Getting closer. I am commenting out the rules in our own eslint.config.mjs for import/no-unused-modules until import-js/eslint-plugin-import#3079 is fixed.

[phun-ky]

Linting is fixed, and I do get one test to run, but with the new test regime (native node test runner), I can't get it to only use the default config in the tests, and it looks up the projects eslint.config.mjs as well. Is that how it is supposed to be?

[JounQin]

Is that how it is supposed to be?

Yes, test files are also linted otherwise it should be listed in eslintignore.

[phun-ky]

@JounQin nono, I meant, that the config passed to ESLint in the tests are merged with the ESLint config in the project root. Is that how it should work?

[JounQin]

Yes, that's how eslint works, test files linting merges and overrides the root, so that we only enable/disable specific rules for test files.

[phun-ky]

So to be clear, when testing, the passed config from the tests should override root, and if no passed config in the test exists, the root take presedence?

[phun-ky]

hm, I see that the current tests has a flaw, or the program it self. with filePath in the test: https://github.com/prettier/prettier-eslint/blob/master/src/__tests__/index.js#L48, shipped to analyze, we run this from ESLint: calculateConfigForFile. This function gets the closes relevant ESLint config file from the DIRECTORY of filePath, not using the rules/config defined in that file. Is this an oversight?

EDIT: I think I have to rephrase this to: the default config used in the tests has no actual usage, right? I tried to put it like this now:

$ struct src/__mocks__
├── eslint.default.config.mjs
└── src
  └── default-input.mjs

And use the path to default-input.mjs to try to find the new default config. But it is not working. ESLint still uses the project root eslint.config.mjs. Since I'm really sure ESLint does not have a bug for this, it is as intended. So, skip eslint.default.config.mjs ?

[JounQin]

What is eslint.default.config.mjs? That would not be automatically loaded AFAIK.

[phun-ky]

the equivalent of this: https://github.com/prettier/prettier-eslint/blob/master/src/__tests__/index.js#L57

[phun-ky]

Let me see if I get this correctly:

If you use format with:

1. no filePath and no config passed

1. The nearest eslint.config.mjs of cwd (or any other supported config file) is found and used.

2. no filePath and config passed

1. The nearest eslint.config.mjs of cwd (or any other supported config file) is found and used.
2. The config passed is merged into the nearest eslint.config.mjs found.

3. filePath given and no config passed

1. The nearest eslint.config.mjs to filePath (or any other supported config file) is found and used.

4. filePath given and config passed

1. The nearest eslint.config.mjs to filePath (or any other supported config file) is found and used.
2. The config passed is merged into the nearest eslint.config.mjs found.

Does this seem correct? Or should, when config is given/passed (programtically and not from eslint.config.mjs, replace any found config?