-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change Request: Add feature flag capabilities to ESLint #18458
Comments
Makes sense to me 👍 |
How do you plan to handle opt-in features that require additional configuration? In v8 the environment variable If an opt-in feature needs an additional option to indicate how it should work, will the presence of the option be sufficient to enable the feature, or should users specify both a flag and the option? |
Should it also be allowed to opt-in in |
@fasttime The simple answer: we just wouldn't do features like this anymore. We were trying to figure out how to best enable people to use flat config and that's what we came up with. If we had this feature flag functionality, we probably would have just created a flag like
Short answer: in order to enable a feature, the flag must be present. Can you give a concrete example of what you're describing?
@kecrily No. This is a session-specific setting, like |
Thanks for the clarifications. The example I had in mind was exactly the one of the environment variable to control the config type. This is mentioned in the issue description to show the limitations of using an environment variable to opt in to a feature (flat config), but it made me also think about the limitations of not having a value (like "true", "false" or undefined) associated to the flag. I assumed that an additional option would be still necessary to convey that information, alongside the flag. |
I'm not quite sure what you mean. Feature flags are either specified, and so are on, or are not specified, and so are off. Again, I don't think the way we did flat config should be an example of the best way to introduce an experimental feature. |
Unfortunately, flat config support is the only experimental feature I have known in ESLint, so I don't have a better example. I am used to other environments where feature flags are regular options and so they can accept values of several types. Node.js has a few of them, so you could run it for example with |
Ah, I see what you mean. To me, the Node.js approach is more difficult for use because we'd need some way to coordinate passing all of that around internally, meaning we'd need to make a bunch of changes each time a new experimental feature was introduced. With feature flags, we just have one system, so any time we want to add a new feature, we just define a new flag and the relevant code checks for the presence of that flag. We don't need to go through the trouble of adding new parameters to methods, etc. This feature was inspired by what Remix does: |
Yes, that's indeed an advantage 👍🏻 |
This looks to be a fairly small, non-breaking change. Do we want to do an RFC? |
I think RFC isn't needed for this change. |
I'd say a PR is sufficient to discuss this change. |
In that case: #18516 |
ESLint version
HEAD
What problem do you want to solve?
When rolling out flat config, we ended up using an environment variable to let people opt-in. However, that is fairly limited in that you need to be running the CLI on a command line, so those who were using ESLint elsewhere (via the API or in an editor) need to use different methods of enabling flat config.
As we move forward, it seems like the ability to implement changes and let people opt-in will become increasingly important, and without a standard way to do this, we'll end up implementing special opt-in functionality on a per-feature basis.
What do you think is the correct solution?
Introduce feature flags into ESLint.
For the CLI, we'd add a
--flag
option that lets people pass these in:For
ESLint
class, we'd add a new constructor option:For the
Linter
class, we'd also add a new constructor option:Participation
Additional comments
No response
The text was updated successfully, but these errors were encountered: