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.

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?