@waynzh would it be possible to get a review or even just a yay/nay on if you're open to this?

I'm unsure whether an environment variable is the correct approach to this. Maybe it would be better to duplicate the configs with an -error variant for each one?

I'm personally not fussed so if you're happy having double the amount of configs I'm fine to do it that way too - I just figured the env variable was a nice way of leveraging the fact that going forward you have to use a JS file for the ESLint config (meaning its always possible to ensure that the property on process.env is always set when ESLint is running) without doing a breaking change

@ota-meshi @waynzh What do you think?

I've been thinking about this for a few days, and my personal opinion is that I'm against adding new shareable configs or making major changes to them.
It's impossible to satisfy everyone's preferences, so I think it's better for users to create their own configs.
I think this is also related to #1951 (comment).
However, if @FloEdelmann and @waynzh both think this config change is a good idea, there's no problem with accepting it.

@ota-meshi @waynzh What do you think?

I'm not a fan of using environment variables.

For the IDE DX issue, you can address it by configuring the IDE-ESLint integration like this:

"eslint.rules.customizations": [
 { "rule": "*", "severity": "error" }
 // { "rule": "vue/*", "severity": "error" }
]

I'm not a big fan of controlling this via environment variables either.
One thing worth noting is that there's already a (though not very active) discussion in the ESLint core (eslint/eslint#14679) about adding severity settings into ESLint config. If implemented, this would allow severity to be configured through a single field, removing the need for each plugin to provide separate sharable configs for different severity levels.

For the IDE DX issue, you can address it by configuring the IDE-ESLint integration like this:

That only works for VSCode

I'm not a big fan of controlling this via environment variables either.

Sounds like folks are against that, so I'll switch to generating new configs

@FloEdelmann @waynzh @ota-meshi I've updated the implementation to generate dedicated configs instead of using an env variable