Configuring external JSCS and ESLint

[mightyiam]

Continuing from #31, I don't think that a Vim plugin is the correct path to take.

We can leverage existing code to achieve more results if we aim to use the default behaviors of JSCS and ESLint.

JSCS can be directed to a configuration file through package.json.

So if we use the install npm script of standard to inject a property to direct JSCS to our config file, so that it ends up like the following

{
    "name": "some-package",
    "jscsConfig": "node_modules/standard/rc/.jscsrc"
}

Then JSCS will serve us, not matter if it is run through Vim or any other editor/tool, most likely.

Is this about JSCS correct, @mikesherov, please?
Would it prevent JSCS from processing other .jscsrc files in the tree?

ESLint seems halfway there, because it can be configured via package.json but it doesn't have an include directive.

Adding a property to the package.json seems reasonable to me, since our users will see that change and not miss it. And it will be documented and it is only a small change. We just have to figure out how well this works/will work with JSCS and ESLint.

This approach may even simplify Standard's code a little.

[Flet]

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.

[mightyiam]

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

[feross]

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.