IMHO NACK, extending the project is very easy by just using eslint yourself...

@dcousens true, but it won't be JavaScript Standard Style any more!

This extensions proposal allows enjoying official Standard with official extensions. These extensions will be curated to be consistent with the values of Standard.

but it won't be JavaScript Standard Style any more!

And neither will this extended version.

One JavaScript Style Guide to Rule Them All

Extensions aren't compatible with that idea.
If they're good enough to be marked as standard, then it makes sense to have them integrated into mainline.

The only exceptions I've seen related to this is in regards to things like how we handle JSX/React, and could handle Typescript etc.
If that is your intention, then I'm not sure what the exact state of affairs is there, so I'll leave that to @feross.

It is exactly for things like React, JSX and AVA, which should not be added by default to Standard (we had React and JSX and they were removed), yet, we should allow users to choose to use them. And still be able to state truthfully that they are using Standard. Because they are.

Extensions are the de-facto concept for this situation, where subsets of users would like something which should not be in core.

Any thoughts, @feross ?

Another possible extension that I assume will be very highly used could be based on https://github.com/mysticatea/eslint-plugin-node.
One could argue that this one is worthy of inclusion into core. Yet, why bother debating that, when we can make an extension of it? $ npm i --save-dev standard standard-extension-node—done.

One of the main principles of standard is "No configuration". I feel like this goes against that principle, so I'm not in favor.

Extending eslint-config-standard directly with additional rules and using eslint directly feels like a better approach as eslint does extensions/plugins well. If a specific cocktail of rules feels like a good set that many folks need, using standard-engine to build a separate CLI would be the way to go.

Sorry @mightyiam, this is a neat idea but it seems to deviate from the goal of standard.

The principle of "no configuration" serves purposes:

• "I easily install and move on"
• "there's no discussion in the team regarding linting rules"

Further, standard provides:

• "I get excellent curated rules"
• "I'm hip"

Standard extensions, as I defined them, will not override any one of Standard's core rules. They are meant for specific popular libraries like Node.js, AVA, React, JSX, etc.

Therefore, they are hardly "configuration" and will not infringe upon "I easily install and move on".
They will not violate "I get excellent curated rules".
They will certainly only contribute to "I'm hip".

Regarding "there's no discussion in the team regarding linting rules"; the only discussion that could be had is about whether to include an extension or not. Here's more about it:

Without extensions:

• discussion; choosing between:
  • no library-specific rules
  • extending eslint-config-standard, which means: open to discussion regarding any possible eslint rule

With extensions:

• discussion whether to include official, curated, Standard set of rules for each relevant extension

In my heart, the latter wins big time.

This is not about making Standard configurable. On the contrary. The situation now is that anyone who wishes to use any library-specific rules goes ahead and uses eslint directly, extending on eslint-config-standard. This opens the door to configuration, which includes overriding of core rules.

Official and non-overriding extensions remedy that. They:

• provide library-specific official Standard rules ("standard-extension-ava", "standard-extension-node", etc.)
• do not override any of the rules currently in Standard
• official, white-listed, curated set of extensions (not just any "standard-extension-foo" will work)

So extensions are not about configuration. They are about official extension and they in fact discourage configuration by providing a better alternative to using eslint-config-standard yourself.

I'm not against the idea, provided the following was in place:

provide library-specific official Standard rules ("standard-extension-ava", "standard-extension-node", etc.)
do not override any of the rules currently in Standard
official, white-listed, curated set of extensions (not just any "standard-extension-foo" will work)

But, I'm not really phased either way.

I actually think this is an interesting idea. I don't want to make standard configurable, but being able to do, for example: npm install standard standard-react, then run standard and have it apply additional rules for React, for example, is pretty interesting.

However, I want to get standard v9 released first before considering this further.

For reference, Canonical is extensible:
https://github.com/gajus/eslint-config-canonical#usage

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

No! This is a great idea! Don't stale it!

That also should help with cases like Vue and Flow eslint plugins, which are right now impossible to use with Standard at all. Like, really, Vue is on top with React and Angular, and Standard does not support it...

This would be awesome.

This proposal has been sitting here for a while. Is an implementation PR welcome, please?

Story time: The company I work for, Edge wallet, started using Standard.js very early on. It was easy to set up, and things were great!

Soon after, we decided to adopt Flow typing as well. Now things got messy, since Standard.js only understands vanilla Javascript, not language dialects like Flow. So, we did what everyone in this thread is suggesting, and switched to ESLint + eslint-config-standard. This worked.

Unfortunately, we have quite a few repositories at our company, including everything from little helper libraries to our giant React Native application. Each of these repositories now has some random ESLint configuration, depending on when we created it and what other repo we copied the configs from. I spend quite a bit of time going from repo to repo updating linting tools, which would be better spent fixing actual bugs.

So, while Standard.js started off as a simple idea for us, downgrading to ESLint has turned it into a bit of a mess. To simplify things, I made an ESLint configuration tool to automate this process, as well as re-packaging the Standard.js rules in a simplified format, but the config files still get really ugly when you tick all the boxes.

How can this be better? I don't know. Our ESLint configuration also includes things like Git integration, so extending Standard.js to support dialects like Flow wouldn't solve everything.

I see three main options:

1. Standard.js remains minimalist, and only supports vanilla Javascript. If you want more coverage, you switch to ESLint.
2. Standard.js support the kitchen sink, including language dialects (Typescript, Flow, JSX, ESnext, etc.) & frameworks (React, Ava, Vue, etc.). If you want more coverage, you submit a pull request.
3. Standard.js supports the kitchen sink, but you have to "pay for what you use" via an extra npm install. If you want more coverage, you can write a plugin.

Of the three options, 1 and 3 seem the most long-term sustainable for Standard.js itself, while 3 would be the most sustainable for both the project and its users.

Thank you so much for your input, @swansontec.