Extensions proposal (not about making Standard "configurable")

[mightyiam]

Extensions proposal

Background

In the past we had a React and a JSX plugin. To avoid bloat, these were removed from standard. Were they dependencies? I've recently suggested an AVA plugin and it was refused to avoid bloat.

Avoiding bloat is great. Yet, as it is, feross/standard is not extensible. So, in order to use feross/standard and probably all other front-ends for Flet/standard-engine combined with some other set of rules, like for React or AVA, one would use ESLint directly, extending on feross/eslint-config-standard.

Use

What if all one had to do, is to install standard and some extensions and it would just work?

$ npm --save-dev install standard standard-extension-react standard-extension-ava

Zero configuration. Just like that.

Principals

No duplicate rules

There would have to be an assertion in standard-engine that none of the rules from plugins override any rule from eslint-config-standard and perhaps also that they do not override any of each other's rules. In short, no overrides at all. No duplicate rules.

Curation

Now, not just any package with the name standard-extension-* would work. The extensions will be curated/white-listed in feross/standard and possibly owned by the same team. Or perhaps we should make it an organization (but that's a tangent).

Going forward

Please provide feedback:

• Do the maintainers of standard and standard-engine find the concept of extensions agreeable?
  • Do you agree with the suggested form of usage?
  • Do you agree with the principals laid out?

Candidate extensions

typescript

Would be based off of the existing eslint-config-standard-with-typescript.

end-project

A project that is not imported and used as a library / package in another project.

• @typescript-eslint/no-unnecessary-condition
  The only issue with enabling this in core is described here.

react

Rules that are specific to React. Perhaps includes JSX? I'm not familiar with the ecosystem.

[mightyiam]

Of course, these do not exist, yet.

[dcousens]

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

[mightyiam]

@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.

[dcousens]

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.

[mightyiam]

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.

[mightyiam]

Any thoughts, @feross ?

[mightyiam]

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.

[Flet]

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.

[mightyiam]

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.

[yoshuawuyts]

Yeah let's not make standard configurable. For me personally this would be interesting as I'd love to disallow almost everything in ES{6,7}, but I think that'd best be served as a separate package.

…

On Tue, Nov 29, 2016 at 10:05 PM Shahar Or ***@***.***> wrote: 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: - no discussion - one of - 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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#703 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWleq6gaadEQsViyBZ1sNIzd2aGCoC_ks5rDJOmgaJpZM4K79qm> .

[mightyiam]

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.

[dcousens]

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.

[feross]

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.

[mightyiam]

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

[stale]

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

[mightyiam]

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

[ArmorDarks]

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...

[DiegoRBaquero]

This would be awesome.

[mightyiam]

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

[swansontec]

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.

[mightyiam]

Thank you so much for your input, @swansontec.