Suggestion: splitting core out

[mattdesl]

Just flowing some thoughts here, let me know if you guys are interested or not.

What if the core was split into its own module to better facilitate forks like semistandard and create an ecosystem like google-standard, airbnb-standard, etc. The module would just handle ESLint reporting with a given config. Then standard would be a thin wrapper around that module, using the current .eslintrc.

Having everybody on the same page is great for npm as a whole, but also a difficult goal to attain given the diversity of JS devs and their work. For example; a lot of client work I do gets touched by many devs (freelancers, juniors, co-op students, etc) and runs on very tight deadlines. Rules like newline at end of file, space after comments, single quotes only slow down our development and lead to distracting lint noise.

However, it would still be beneficial for us to have a tool like jam3-standard so that our modules can catch true syntax errors. It also means that we can releases changes to our code style using SemVer, which is (in my view) a huge innovation brought forward by standard.

[Flet]

A nice command line wrapper around an .eslintrc file is an interesting idea.

I don't know if letting a thousand standards bloom fits with the initial motivations of creating this tool. An all purpose wrapper may require some broader design decisions, such as bringing in additional linters.

I guess all it takes is someone motivated enough to fork and work on it!

[jprichardson]

I'm against this unless it somehow benefits standard.

Creating a google-standard, airbnb-standard, etc are antithetical to the goal of standard. Fortunately standard is OSS, so if someone really wants to, they could easily clone it and create google-standard and friends similar to how semistandard was created.

Having everybody on the same page is great for npm as a whole, but also a difficult goal to ascertain given the diversity of JS devs and their work. For example; a lot of client work I do gets touched by many devs (freelancers, juniors, co-op students, etc) and runs on very tight deadlines. Rules like newline at end of file, space after comments, single quotes only slow down our development and lead to distracting lint noise.

Totally understand your concern here. My suggestion would be to just create simple eslint rules that suit you and your team's development and expand from there.

[mattdesl]

@jprichardson

The benefits: separation of concerns, modularity and semantic versioning. e.g. A hypothetical eslint-error-stream module could be versioned independently of the rc files that standard uses. If standard decides to drop ESLint, it would be trivial to just remove it as a dependency.

Forking standard is bound to lag behind; it's a burden to constantly pull in patches.

My suggestion would be to just create simple eslint rules that suit you and your team's development and expand from there.

I already have. The reason a tool like standard is attractive is because (a) I don't need to maintain rc files for each module and (b) changes in the style guide can be represented by SemVer (i.e. as new patterns and language features are introduced).

[yoshuawuyts]

Rules (...) only slow down our development and lead to distracting lint noise.

The way golang developers solved this is by having go fmt run on every file save through editor plugins. Doing the same with standard-format might be the right way to tackle this.

[Flet]

@mattdesl you've piqued my interest with this idea. Exploring it now... Will probably use semistandard as a test subject.

[Flet]

OK so I did this: https://github.com/Flet/standard-engine (a bit rough still, be gentle 😄 )
And I'm using it now with semistandard.

So now making a cli linter is just creating a new module with a cmd.js and an eslint rc file:

#!/usr/bin/env node
var path = require('path')
var pkg = require('./package.json')

require('standard-engine').cli({
  // cmd, homepage, bugs all pulled from package.json
  cmd: 'semistandard',
  homepage: pkg.homepage,
  bugs: pkg.bugs.url,
  tagline: 'Semicolons For All!',
  eslintConfig: {
      configFile: path.join(__dirname, 'semistandard.eslintrc.json')
  }
})

[yoshuawuyts]

@Flet Lolol, that interface is ridiculously simple. Leaving in the middle if having multiple standards is a good idea, standard-engine is pretty cool!

[mattdesl]

🎉

@Flet
This is great. I'm trying this out now.

I was also thinking having a formalized JSON (or HJSON) export for standard might ease maintenence of semistandard et al since you are just pulling in the config as a dependency, and changing only a couple of select rules. e.g. require.resolve('standard/rc/.eslintrc')

^{(annoyingly ESLint uses different semantics for configFile, like "globals" as an object rather than array)}

@yoshuawuyts

.. if having multiple standards is a good idea

Ideally there would just be one, but realistically it will be a long while before I can convince a team of devs to change styles and adopt new editor tooling on the drop of a hat, and much longer before the entire community stops quipping about semicolons, tabs etc. Until that time, I'd still like to reap the benefits of standard (versioned and centralized rc files for many modules).

Thinking long term, maybe the core engine should just be named eslint-reporter or something generic as to not marry it specifically to standard and its tooling? And the "growth" would just be in the form of lint-airbnb or lint-jam3. If you want all the other goodies (formatters, SublimeLint packages etc), then you should just pick standard in the first place.

[pluma]

It's either this, or drop the anti-semicolon rules in standard so this module can actually become something of a standard convention. This module claims to represent a consensus of the JS community but seems to be at odds with what the majority of the community agrees on (e.g. semicolons, spaces after function names). We chided Crockford for how opinionated he made jslint, let's not repeat that with standard.

There are already competing style guides, standard is not going to change that. If standard can improve the formalization of those style guides, it adds value. What's more, if standard's core can be used to make the specifics easily swappable (i.e. allow re-using the tooling that can be built around standard to work with other style guides too), it encourages users to switch to standard because the failure scenario (i.e. what if they don't like it and want to go back) is a lot less expensive.

Having only one style guide for the entire language is not going to happen. Look at Python: the language itself is fairly unflexible, the core ethos is "write for the future maintainer, not yourself" and the style guide, PEP8, is as offically blessed as possible. Yet there is tons of software out there that doesn't use the same style guide for various reasons. PEP8 conformance is generally seen as a good thing, yes, but even open source codebases don't always adhere to it.

The only example of a universally accepted style guide I can think of is Go and Go has the benefit of having it built right in the tooling (and not having any alternative language implementations like, say, JavaScript has by the dozen).

[jprichardson]

It's either this, or drop the anti-semicolon rules in standard so this module can actually become something of a standard convention.

In time, I believe this will become the predominant "standard" convention. I plan on using it in all of my modules (> 100). Heck, I've even thought about giving some talks about project and the impact that it will have.

We chided Crockford for how opinionated he made jslint, let's not repeat that with standard.

While closely related, jslint and standard solve different problems. standard doesn't hide its opinionated nature.

There are already competing style guides, standard is not going to change that.

Yep. But fortunately this isn't a "guide". This is more than a "guide". This is the "law" (for those that use and adopt it). That's precisely what all of the guides missed before.

If standard can improve the formalization of those style guides, it adds value. What's more, if standard's core can be used to make the specifics easily swappable (i.e. allow re-using the tooling that can be built around standard to work with other style guides too), it encourages users to switch to standard because the failure scenario (i.e. what if they don't like it and want to go back) is a lot less expensive.

Fortunately there's eslint or the work that @Flet did.

[pluma]

Not to derail this conversation further, but @jprichardson, what makes you think this will become the predominant convention? A few years back comma-first was all the rage and now we all agree that wasn't as brilliant as we thought (although the @isaacs article linked in the README mentions it). Semicolon-free syntax has been a thing for at least as many years but doesn't seem to be going anywhere (according to various surveys and an analysis of actual code styles on GitHub). It also doesn't buy you much other than making the code look more like Ruby (having to prefix IIFEs and array literals with an unary operator or semicolon is a major nuisance). So far the only thing standard has going for it is that some people use it (so what?) and the tooling, which standard-engine is trying to generalize.

[mattdesl]

@pluma Please let's not derail this any further; this thread is not about semicolons.

This is a proposal to split out the "guts" of standard so that other modules and tools (like semistandard) can reap the same benefits without having to maintain a fork. It is not an attempt to change the philosophy or eslint rules of standard (which is why I'm suggesting the name of eslint-reporter rather than standard-engine).

[Flet]

@feross let me know what you would like to do here. Open to anything including transferring standard-engine to you or deferring to a new repo.

I feel that abstracting the core fits the spirit of the ecosystem and allows others to iterate on their own nicely.

[Flet]

FYI, updated standard-engine to make merging less painful and was able to sync it up with this repository.

[Flet]

This has been done!

standard-engine is now used by standard

Released as 5.0.1 by @feross! 🎉