we are modifying some of their rules’ behavior.
Ah, so that would be why there’s so many rules duplications. I have some issues with how it’s currently handled, but I’ll open a different post with more details and some possible suggestions.
I agree we should provide different profiles of recommended configurations depending on each user’s needs.
That would be lovely, ESLint is already a pretty slow tool, no need to bloat it by enabling more rules I can’t possibly be using in a project 
It will simplify our shared configs too.
we cannot put it as an optional dependency because we are modifying some of their rules’ behavior.
If the rules aren’t used, there’s no need to modify them, hence for them to necessarily be present. A clear error could be presented when trying to use one of those rules from an eventual preset, with the plugin missing. (just like ESLint already gives a clear error when trying to use a preset or rule for a plugin not installed or not imported).
Any chance to make JSX/Vue/React dependencies optional as well for non-jsx projects ? It could be a sonarjs-jsx plugin if you don’t want to make the dependencies optional. Here’s 2 reasons I can think of:
- Reduce package size. Yes this actually really matters when using a tool like pre-commit.ci on the free tier. See this example where I’ve added special casing to not load and run a bunch of plugins under that context, and have to tell my users to explicitly omit them: eslint-config-beslogic - npm (npmjs.com). An Angular dev, for instance, doesn’t need React/Vue dev packages (it’s also just generally nicer on the ecosystem, JS/npm has a very bad wrap for being bloated for a reason ^^" )
- Reduce false-positives from
npm audit. You’re probably already aware of this as a company that deals in Software Security, but here’s my 2 usual references: npm audit: Broken by Design — overreacted & https://github.com/facebook/create-react-app/issues/11174