Enable Flat Config by default

[polyzen]

Flat Config is now considered complete:
eslint/eslint@7162d34

Seems it should no longer be masked behind eslint.experimental.useFlatConfig.

[dbaeumer]

This might not be easy to enable by default since the ESLint server doesn't start on the workspace folder root.

[ghost]

Flat config is enabled by default from ESLint v9.0.0 and the ".eslintrc.*" format seems to be removed in v10.0.0
https://eslint.org/blog/2023/10/flat-config-rollout-plans/

[chojnicki]

Any ETA on that? It's pretty weird that it's considered as experimental feature. It should be default for sure since flat config is becoming standard. Extension should keep up with library :)

[aladdin-add]

shouldUseFlatConfig can be used for this honor.

const {shouldUseFlatConfig} = require("eslint/use-at-your-own-risk");

shouldUseFlatConfig();

[nzakas]

@dbaeumer I think shouldUseFlatConfig() probably helps with this? If not, and you need something else, let us know.

[dbaeumer]

@nzakas the reason why I haven't switch yet is that I am under the impression that to get to the new FlatESLint class I still need to import 'eslint/use-at-your-own-risk' which I always interpreted as not being final yet.

Has this changed? What I would like to do is to import eslint normally and then have a flag shouldUseFlatConfig. Is this possible?

[nzakas]

@dbaeumer the /use-at-your-own-risk entrypoint is intended to let people know that these APIs won't be around forever, more than anything else.

For the latest v8 and all of v9, FlatESLint, LegacyESLint, and shouldUseFlatConfig() are all available through that entrypoint. They'll be removed in v10 (whenever that happens).

Full details here:
https://eslint.org/blog/2023/10/flat-config-rollout-plans/

[dbaeumer]

Reading the link from above brought me to the following conclusion:

• 8.x : flat config is not the default an needs to be enabled via an env variable ESLINT_USE_FLAT_CONFIG or when a flat config file exists in the workspace root. Since a lot of VS Code users start VS Code from a dock it is not easy to inject env variables based on workspaces. This is why I introduced the eslint.experimental.useFlatConfig since it gives control over this per workspace. We can debate the name (e.g. the experimental part) but I think it is not worse it to change right now. What I can add is code that checks if ESLINT_USE_FLAT_CONFIG is set and then automatically set eslint.experimental.useFlatConfig.
• 9.x: flat config is the default unless explicitly disabled. Her the fun begins :-). I can only determine the version of ESLint after I have loaded ESLint. If I get < 9.x I need to reload ESlint from /use-at-your-own-risk in case users opted into flat config.
• 10.x: more version checks and more if then else code blocks since now the behavior of the classes have changed (ESLint -> FlatConfig).

From my experiences designing API, it would have been easier for API users, if the API would have added new names and removed old names instead if reusing names and changing the meaning. The first would have avoided checking the version since the pure existence of a name would introduce a behavior. In VS Code we usually use a function to load the API to which you can pass a parameter to determine if you want proposed API. If you opt into this they are put into the same namespace.

@nzakas any change to revisit the rollout plan especially around the meaning change of ESLint -> FlatESLint.

[nzakas]

I appreciate the feedback, but at this point we are weeks away from a beta (three alpha releases have already been published), so revisiting the rollout plan really isn't in the cards.

To clarify: the change to the behavior of ESLint begins in v9, not v10. This is also why we've added LegacyESLint as a sibling to FlatESLint to give people something solid to hold onto should they decide to support both.

In VS Code we usually use a function to load the API to which you can pass a parameter to determine if you want proposed API. If you opt into this they are put into the same namespace.

Can you give an example of this? I'm not opposed to adding something along these lines, but need to see it in action in order to evaluate.

[dbaeumer]

Actually I don't want to change the timing. I understand that this is not possible. I was more hoping for some sort of additional API to make this easier for API users that need to support 8.x, 9.x and 10.x

Let me first explain what we do in VS Code and LSP to mitigate those changes. In general we do two things:

• proposed API has NO special name space. This avoid that when we move things to final names stay the same
• we don't reuse deprecated names

VS Code

• we patch the node loader. So if you require('vscocde') we consult the extension's package.json file and inject those proposed APIs into the returned literal the extension opted into.
• in LSP the API exists on the client / server. So when you construct these you can pass in flags to tell which of the proposed API you want to use. A good example is here that opts into all proposed new API: https://github.com/microsoft/vscode-languageserver-node/blob/2d33852e06ff9f180abd528be464f02b9bbd3079/testbed/server/src/server.ts#L27

ESLint

For ESLint it would be cool to have the following:

• they top level API (when requiring eslint) exports a function resolveAPI(proposed: boolean).
• the return literal would have the following entries

{
     shouldUseFlatConfig?, // Function as described
     ESLint?, // The current ESLint class
     ESLint2?, // The flat eslint class
     Linter?, // The current linter class
     Linter2?: // The flat linter class
}

If proposed is false then the 2 classes and the shouldUseFlatConfig would not be there.

Something like this would allow to use the API without checking version to interpret names differently.

Let me know if something like this would be possible?

[nzakas]

Because we are getting into API design, let's continue this conversation in the ESLint repo here:
eslint/eslint#18075

[fasttime]

• 9.x: flat config is the default unless explicitly disabled. Her the fun begins :-). I can only determine the version of ESLint after I have loaded ESLint. If I get < 9.x I need to reload ESlint from /use-at-your-own-risk in case users opted into flat config.

No need to load the ESLint class directly: the version of ESLint can be determined from "eslint/package.json". It's exported in all versions of ESLint v8.

I was more hoping for some sort of additional API to make this easier for API users that need to support 8.x, 9.x and 10.x

I'm afraid it won't be easy to add an additional API to already published versions of ESLint 8.x. But it could be added in v9 if it simplifies the upgrade to v10.

[nzakas]

The new API has been released in both the v8.x and v9.x branches:
https://eslint.org/docs/latest/integrate/nodejs-api#loadeslint

[lubaker]

@dbaeumer with the new API provided by ESLint does that mean that a single VSCode workspace will be able to use both flat and eslintrc configs depending on what ESLint files exist in the current working directory when using ESLint 8?

It appears that the current eslint.experimental.useFlatConfig setting either uses flat config everywhere or eslintrc configs everywhere regardless of what ESLint config files exist in the relevant directories. For example when using ESLint 8, ideally the VSCode plugin matches that version of ESLint's behavior in the sample project below by using the eslintrc config in package1 and the flat config in package2.

project
├── package1
│   └── .eslintrc.json
└── package2
    └── eslint.config.js

[dbaeumer]

@lubaker I haven't tried the new API so I can't tell yet :-)

[dbaeumer]

Based on the new API from @nzakas I created a new alpha version of the extension. It can be found here: https://github.com/microsoft/vscode-eslint/releases/tag/3.0.1-alpha.1

If you use 8.57.0 or above it should auto detect flat config. I also has a big change to move to pull diagnostics which gives us better validation scheduling and validating on focus change.

To install it download the VSIX and execute the command Extensions: Install from VSIX

Would be great to get some early feedback since most of my repositories are still using the old config style :-)

[lubaker]

Would be great to get some early feedback since most of my repositories are still using the old config style :-)

This appears to work for me. I'm using ESLint 8.57.0 with your alpha and the "Use Flat Config" setting unchecked. In a directory with a flat config, it is linting using the flat configuration and in directories with the old config style, it lints using that config. 💯

[aladdin-add]

eslint v9 has been released: https://eslint.org/blog/2024/04/eslint-v9.0.0-released/

[nzakas]

@dbaeumer is there a timeline for a beta or final release?

[dbaeumer]

I want to release a new version (not pre-release) beginning of next week. However there will still be a loose end with yarn pnp and mjs files. The details are here: yarnpkg/berry#6219

To make that work we need a new yarn version and VS Code being move to Electron 29 which will be the case with the next stable release.

[vtintillier]

I want to release a new version (not pre-release) beginning of next week. However there will still be a loose end with yarn pnp and mjs files. The details are here: yarnpkg/berry#6219

To make that work we need a new yarn version and VS Code being move to Electron 29 which will be the case with the next stable release.

Hello @dbaeumer ,

is there anything preventing releasing a new (not pre-release) version containing this change? And later another minor/patch version containing the yarn fix you mentioned?

Thanks

[dbaeumer]

Shipped 3.0.10 today.

[karlhorky]

@dbaeumer and others involved, thanks for the work getting this published!

What is the upgrade path for users who want to use flat config (or who want to opt out of flat config) on ESLint version 8, 9, and 10? Eg:

1. If a flat config user is on ESLint v9, can they remove the eslint.useFlatConfig config setting altogether, because it defaults to true? (I would expect this)
2. If a non-flat config user is on ESLint v9, they need to add the eslint.useFlatConfig: false setting, because it defaults to true? (I would also expect this)
3. etc

It seems like from the flat config rollout plans like the eslint.useFlatConfig setting default may be different, but I didn't find any documentation on that.

I opened an issue over here about adding docs about eslint.useFlatConfig setting defaults / divergent behavior on different ESLint versions:

• Document behavior and defaults of useFlatConfig across ESLint v8, v9, v10 #1879