Implement Flat Config

Question

Implement Flat Config

nzakas opened this issue 4 years ago · 27 comments

Any news?

👎13

Answer 1 · 2020-08-24T17:05:26.000Z

Update: Most of the CLIEngine tests are so tightly coupled to the existing file structure (overriding and stubbing require imports and then trying to use an in-memory file system) that there's just no way I can get all of the tests to pass. I suspect that the tests aren't actually testing what we think they are due to this complexity. It seems my only path forward is to leave the eslintrc functionality in place in the eslint repo and then make a copy in the eslintrc repo. We will just have to focus on removing the eslintrc functionality when we remove CLIEngine.

Answer 2 · 2020-08-27T20:43:31.000Z

I'm going to make one more pass but using a physical file system instead of an in-memory filesystem to see if I can disentangle the tests. If that doesn't work, I'll do a more minimal extraction and move on.

Answer 3 · 2020-10-28T19:09:59.000Z

Phase 1 is now compete. The old config system has been separated out into a separate package. That means I can now move on to phase 2. 🎉

Answer 4 · 2020-12-02T16:34:45.000Z

Sorry for making this question for such a long process, but, do you have an idea of when this will be done? I am really interested about the #3458 implementation, so I can have my simple all-in-one-ESLint config.

Some hours ago and while writing this, I have been developing this idea (which I don't think would worth creating a new Issue), which could be done via the eslint-config package.json scripts but really could be a ESLint default functionality:

npx eslint install @srbrahma -e ts react

This would install eslint to the current package if needed, and also install the @srbrahma/eslint-config to the project.
The eslint version, if not installed, would be defined by the eslint-config package.
The -e flag would then extend the eslint-config ts and react sub-configs (adding them/creating the new eslint.config.js).
npx eslint install srbrahma would install eslint-config-srbrahma.
Running again with or without the -e flag, would npm install the config again to update it and its deps and keep the existing extends.

ESLint is hugely awesome, but is also considerably time consuming to set up the environment and to update all the plugins for each project. There could be this single magic cli that would do everything, to quickly maintain and create new projects. It really doesn't seem to be too complicated to set this up, being the #3458 implemented. I think it would really take ESLint to a new level :)

Answer 5 · 2020-12-03T01:10:18.000Z

@SrBrahma It will be at least a year before we’ve transitioned completely to the new config system and probably around three months before you can use the new config system optionally. There are plenty of workarounds mentioned in #3458 in the meantime.

Answer 6 · 2021-03-01T05:34:56.000Z

Could eslint.config.cjs be supported too? This way "type": "module" can be used in package.json even though ESLint doesn’t support loading an ECMAScript module as a config file.

Answer 7 · 2021-03-01T20:25:27.000Z

@valtlai please open a separate issue for that request. This issue is just for tracking implementation of the RFC. Thanks.

Answer 8 · 2021-03-03T20:07:19.000Z

@valtlai please open a separate issue for that request. This issue is just for tracking implementation of the RFC. Thanks.

Done, that’s issue #14170.

Answer 9 · 2021-10-07T20:55:39.000Z

An update on the approach: It turned out to be too difficult to modify the ESLint class to toggle between the new and old config systems, so instead I'm creating a new FlatESLint class that will be the basis of the new config system. cli.js will search for the new config file and use FlatESLint instead of ESLint if found. As a final step, we will remove the original ESLint class and rename FlatESLint to ESLint.

Answer 10 · 2022-01-04T18:02:42.000Z

It looks like I'm going to have to create a FlatRuleTester that mirrors RuleTester in the short term. There are just too many differences between flat config and eslintrc to allow for an easy switch inside of the current RuleTester. The plan is to implement FlatRuleTester as a temporary utility to allow people to test their rules with flat config. Eventually, we will delete the current RuleTester and rename FlatRuleTester to RuleTester.

Answer 11 · 2022-01-20T18:14:12.000Z

An update on FlatESLint: I actually have lintFiles() and lintText() working. The complicated part is dealing with ignored files. We are currently using FileEnumerator as a catch-all that does globbing, config calculation, and ignore handling, and that doesn't really work with flat config. So, I'm in the process of pulling that apart and trying to get the same behavior with FlatESLint. Unfortunately, it looks like we won't be able to get the exact same behavior because FileEnumerator deals with files in sequence while globby deals with them in parallel, so I'm doing my best to get as close as I can.

Answer 12 · 2022-10-31T21:54:20.000Z

I think it would be a good idea to include @typescript-eslint in the Phase 3 list.

IMO onboarding the project as early as possible is a hard requirement for the workstream. Without ts-eslint's onboarding the majority of ESLint users won't able to transition to flat configs without needing to use the compatibility tooling.

For reference - by weekly download volume @typescript-eslint/eslint-plugin users make up over 65% of ESLint users and @typescript-eslint/parser users make up over 70% of ESLint's users.
(plugin = 19.2m / parser = 21m / eslint = 28.8m)

It would be a real shame if most users' first experience with new config system involves reaching for the compatibility APIs. Making sure that doesn't happen should be a top priority!

Feel free to chat with us (cc @JoshuaKGoldberg and @JamesHenry)!

Separately but very related to the above - I'd also suggest including eslint-plugin-import for the same reasons given that it is similar in size (17.1m - ~60%).

Answer 13 · 2022-10-31T23:09:54.000Z

Could not agree more @bradzacher. The success of tools like Next.js, Jest, Prettier and even Create React App proves that many users want simple tools, they need fast onboarding and prefer opinionated presets.

It's great to have a configurable tool, but for majority of users thousands of options are overwhelming. People simply do not have time to dig into nuances, they need a solution.

In my opinion, ESLint should provide some dead easy way to kick off a fresh project with all necessary dependencies. Something like npm install eslint && eslint init recommended. Look at the guide https://eslint.org/docs/latest/user-guide/getting-started and https://eslint.org/docs/latest/user-guide/configuring/configuration-files-new — and imagine what most users think while reading this...

Answer 14 · 2022-11-01T17:26:26.000Z

@bradzacher will do. The intent is to use phase 3 to test the ecosystem in general.

@kirill-konshin this is off topic for this issue, but you can use npm init @eslint/config. It’s listed right on eslint.org. 😄

Answer 15 · 2022-11-01T18:11:26.000Z

Thanks a lot to @sxzz since eslint-define-config v1.8.0 Flat ESLint Config is officially supported by my plugin 🚀

Answer 16 · 2022-11-23T20:07:11.000Z

@mahnunchik you can look at the checklist in the original comment to see the current progress.

Answer 17 · 2023-01-11T09:36:10.000Z

Work with eslint-plugin-react to switch configs to new format and ensure it works correctly

@nzakas now that the new config format has been added in jsx-eslint/eslint-plugin-react#3429, should this checkbox in Phase 3 be checked?

Answer 18 · 2023-01-11T17:58:15.000Z

eslint-plugin-react v7.32.0 has been released, with flat config support - but only less than 12 hours ago. It's probably wise to wait a bit longer to make sure it actually does work correctly :-)

Answer 19 · 2023-02-09T06:24:09.000Z

Guys, I hope I ask in the right place and time for the phase 3. What will be the best convention to export shared config for plugins maintainer to follow?

I hope it can be consistent so plugin user can set recommended shared config in a same way across plugins.

I afraid, the old plugin configs is not compatible be used directly because it may have extends, overrides and plugins type array of string instead of object in the shared config. If we upgrade the configs, I don't think we can make it "hybrid" to support both old and new config at the same time. It must be exposed trough a different way to make it backward compatible.

Examples

The eslint-plugin-react approach above looks promising. The new shared config exposed trough a deep import path:

const reactRecommended = require('eslint-plugin-react/configs/recommended');
// The old configs is still in here: reactRecommended.configs.recommended for backward compatibility.

module.exports = [
  …
  reactRecommended,
  …
];

However the Configuration Files New doc recommends like below. Similar like in the RFC Plugins Specifying Their Own Namespaces which I believe it will be breaking for some plugins 🤔

// doc
import jsdoc from "eslint-plugin-jsdoc";
export default [
    // configuration included in plugin
    jsdoc.configs.recommended,
    // other configuration objects...
];

// RFC
module.exports = [
    require("eslint-plugin-example").configs.recommended,
    // ...
];

Answer 20 · 2023-02-10T20:36:20.000Z

This is a tracking issue and not the best place to ask for help. Please open a discussion instead.

Answer 21 · 2023-02-12T14:23:55.000Z

This is a tracking issue and not the best place to ask for help. Please open a discussion instead.

My intention was to get a chance to help or send PR for some plugins since I already study the code of the flat configs on both Eslint and some plugins. It could be the way to start contribute to the community on the phase 3.

Anyway, in that case, you may update somewhere about the concern above whenever Eslint team is ready.

Answer 22 · 2023-02-13T21:04:15.000Z

@CallMeLaNN that's great, we'd appreciate the help...but this is still not the right place for that type of question. Happy to continue in a separate discussion.

Answer 23 · 2023-03-11T10:37:17.000Z

This looks really promising and a huge step forward.

I cannot seem to find an answer to my issue: How to use .gitignore as a default ignore file ?

Previously there were the --ignore-path command line option, I would expect this command line to be migrated to the flat config but cannot seem t find anything about this (https://eslint.org/blog/2022/08/new-config-system-part-2/, https://eslint.org/docs/latest/use/configure/configuration-files-new).

Furthermore it looks like the .eslintignore file does not work anymore.

What is the recommended way ? I think a documentation change / migration guide may be required to clarify this.

Solution 1: copy-paste and maintain

Re-introduce .eslintignore
cp .gitignore .eslintignore
maintain both files

Solution 2: symbolic link

Re-introduce .eslintignore
ln -s .gitignore .eslintignore

Solution 3: configuration option

Introduce an "ignorePath" option that would read a .gitignore like file and apply it

Solution 4: configuration utilities

Stick with the "ignores" configuration, but provide a utility function to easily convert .gitignore to "ignores"

...
    "ignores": ...fromGitignore('.gitignore'),
...

Solution 5: do not change anything

Let people re-define manually their .gitignore in "ignores" and keep them in sync

My point of view

I guess the most consistent solution is the 4th one (configuration utilities). The user may be responsible to read the file as a string, but I guess this use case is pretty common so doing it within the utility may reduce boilerplate.

The 3rd solution may be easier to discover, but may introduce some inconsistencies

Other solutions should be avoided to me.

Answer 24 · 2023-03-12T00:59:47.000Z

@homersimpsons "ignores" can also contain custom functions that should return true if the given file/directory path should be ignored. For gitignore-like patterns, you can use the ignore package. Config file that loads a .gitignore file could look like this:

// eslint.config.js

import ignore from "ignore";
import { readFileSync } from 'node:fs';
import path from 'node:path';

const myIgnore = ignore().add(readFileSync(".gitignore", "utf-8"));

export default [
    {
        ignores: [
            absolutePath => { 
                const relativePath = path.relative(".", absolutePath);

                if (relativePath === "") {
                    return false;
                }

                return myIgnore.ignores(relativePath);
            }
        ]
    },
    {
        // other configurations
    }
];

Answer 25 · 2023-03-14T17:56:48.000Z

Folks - if you have questions about flat config, please open a discussion rather than commenting here. This issue is for tracking purposes only.

Answer 26 · 2023-09-21T20:25:33.000Z

Remove context.parserPath, context.parserOptions, context.globals in Linter

Does context.globals exist?

Implement Flat Config

Phase 1: Extract current config system

Phase 2: Implement flat config with `eslintrc` compatibility

Phase 3: Compatibility testing

Phase 4: General availability (v9.0.0)

Phase 5: Remove `eslintrc` (v10.0.0)

Examples

Solution 1: copy-paste and maintain

Solution 2: symbolic link

Solution 3: configuration option

Solution 4: configuration utilities

Solution 5: do not change anything

My point of view

Phase 1: Extract current config system

Phase 2: Implement flat config with eslintrc compatibility

Phase 3: Compatibility testing

Phase 4: General availability (v9.0.0)

Phase 5: Remove eslintrc (v10.0.0)

Examples

Solution 1: copy-paste and maintain

Solution 2: symbolic link

Solution 3: configuration option

Solution 4: configuration utilities

Solution 5: do not change anything

My point of view

Phase 2: Implement flat config with `eslintrc` compatibility

Phase 5: Remove `eslintrc` (v10.0.0)