Configuring external JSCS and ESLint about standard HOT 3 CLOSED

I like the idea of standard being fairly opaque without the actual linters or configuration leaking out. This means that its easy to change to something completely different without impact. For example, standard used to run jshint for several rules, but its been switched over to use eslint now. With the above approach, this may have been a bit more complicated to pull off without impact to users.

It feels like this approach is more about extracting the rules themselves and running them in their respected linters directly instead of having a singular linting tool.

In situations where the command can't be run (or no plugin exists) I could see the benefit of directly extracting those rules and running them in their native linters could be a way of solving the problem.

Perhaps adding --eslint-rules and --jscs-rules commands to output the rulesets could be a compromise here? This would allow a separate module to be built that does exactly whats described above.

from standard.

@Flet I hear you completely.

Standard should, itself, provide the utility that makes it so that by default my Vim does the right thing in the Standardized project. So I don't like the idea of another module.

If possible future switching of tools is the issue here, then the standard command can, itself (vs the npm install/postinstall script) make sure that the correct directives are in package.json.

Then, when Standard uses a different tool, in the future, it can quickly and easily make sure that that tool is configured correctly via the package.json when it is used externally.

from standard.

Sorry @mightyiam – this isn't going to happen. Install scripts are janky, error-prone, and an anti-pattern.

For vim support, just install Syntastic which now support standard out-of-the-box.

from standard.