Require "standard" field in package.json

[anandthakker]

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?)

[dcousens]

For me, half the point is my modules may have forgotten standard, but standard didn't forget them. I just don't have to think about it.
If collaboration or tests [or any dependencies] become a thing, it gets added pretty quick thereafter.

This is going to be very subjective based on the users pre-disposition to varying ... configurations.

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

[anandthakker]

Will you not be able to use standard to lint standalone files anymore then? Or a subdirectory?

I was thinking that the rule would be, "if package.json exists, then it must have a standard field."

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.

When you use standard, you're choosing to be forced to comply with a set of code style rules. Some of them (like requiring one var per variable) even force typing a few extra keys. I don't think this is fundamentally different. Moreover, it is incredibly easy to automate, so you wouldn't necessarily need to do anything more.

Checking for standard in devDependencies is okay -- that's what I'll do if (as seems likely) this proposal isn't accepted.

[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!

[anandthakker]

👍 thanks.