Require "standard" field in package.json

Bringing this proposal over from a twitter thread: https://twitter.com/anandthakker/status/776252795972362241

I quite like standard (the rules). My only problem with standard (the tool) is that it makes it difficult to get automatic, in-editor linter errors when switching between OSS projects (most of which I don’t control) that do/don’t use standard. There are, for the most part, three main cases:

1. Project uses standard
2. Project uses eslint, and contains an .eslintrc (or maybe an eslintConfig property in package.json)
3. Project uses neither

I’d be okay setting up vim to inspect the current project and pick, eslint or standard accordingly. However, my (main) issue is that there isn’t a great way to distinguish between cases 1 and 3: if I just default to standard when there’s no .eslintrc, then I get stuck with a bunch of spurious lint errors in projects that use some other linter (or don’t use one at all).

@feross What do you think about the idea of having standard require the standard property in package.json? My reasoning is that this (a) enforces a reliable way to programmatically determine whether a project uses standard and (b) is a very low burden to comply with (standard could even add the field on install?)

[LinusU]

It’s already in there:

readJsonFile('package.json').then(res => {
  return (res.devDependencies && res.devDependencies.standard)
})

I don’t think forcing everyone to add a standard property to the package.json would be a good idea at all. Will you not be able to use standard to lint standalone files anymore then? Or a subdirectory?

It takes away the beauty of standard, which is that I don’t have configure anything at all. I only need to do the very bare minimum (installing a package, adding to scripts.test), I don’t want to be forced to do anything more.

[feross]

@anandthakker I sympathize. Turning on and off the standard linter in your text editor can get tedious.

I need a reliable way to programmatically determine whether a project uses standard

I would check for standard in devDependencies. That is going to be super reliable, and doesn’t require any changes to the way we handle the package.json configuration.

Honestly, the "standard" property in package.json is just a hack to make things a bit easier for larger projects transitioning to standard by offering things like ignoring folders, using an env, or defining some globals. Ideally, these aren’t needed at all.

IMO, the presence of the "standard" field in package.json is a sign that something isn’t ideal about your standard usage. The ideal is no configuration. Right now, the number one reason people configure standard is to set babel-eslint as their parser, but eslint is getting ES7 support very soon, so this reason will soon go away!