Thanks for re-opening this. Do you have a suggestion for how to proceed at resolving this issue?

To be honest, I'm not sure how to handle it.

It's basically the same issue as #1283 and it will emerge every time standard needs to be used with newer technologies. Unfortunately, those techs are popping up too often and developers are forced to adapt to them quickly. However, standard can't and that makes it hard to sell standard to stakeholders.

Options:

1. For such cases use standardx — though, it's a deviation from standard vision. Kinda makes standard itself not that useful.
2. Incorporate any required changes right into the standard — that will bloat lib with not essential features. Besides, as shows experience with TypeScript — it takes wayyy to long, to the point where people start to use other linters just because they can't use it with important tech right now.
3. Allow to add and override rules — unfortunately, it's a deviation from standard vision too.
4. Provide the way to extend or override rules with standard plugins — they'd be a bridge between eslint rules and standard. However, in fact, it's the same as 3, but only masked.

@ArmorDarks how do you feel about #703?

Honestly, I'm leaning towards just supporting flags that add extra rules and make fixes for each type of environment we want to support.

standard --react
standard --vue
standard --typescript
standard --typescript --react // allow them to be stacked

Then, most users can just avoid ESLint plugins and the extra work to install them, configure them, debug them, etc. and we can even start to add additional opinionated rules for React apps, Vue apps, etc.

We can still keep standard --plugin around as an escape hatch (like we do today) but hopefully a lot fewer users will need to use it.

Thoughts?

I prefer my #703. With #703, you'd install and keep updated a set of 'standard' packages and then you'd not need to be concerned with flags, because standard will automatically detect and use the installed packages. Flags seem contrary to what standard is trying to be - a zero configuration utility. I wouldn't like to diverge from the beauty of simply running standard. Yet, installing one or more packages to support a specific transpiled-to-JS language or a library seems reasonable to me.

Just for the history, the relevant discussion keeps going here #1356