Add "env" config to package.json

[gsklee]

As a continuation of #18, can we add this?

{
  "standard": {
    "env": "mocha"
  }
}

IMHO it's better than either adding /* eslint-env mocha */ to all test files, or adding:

{
  "standard": {
    "globals": ["beforeEach", "describe", "it", ...]
  }
}

[dcousens]

IMHO, if /* eslint-env mocha */ is a thing, than this is exactly what should be added to all test files.
I don't think blanket application of a mocha env to an entire project is acceptable, though this could be different for other environments.

[rstacruz]

bad, mocha. one of the reasons I don't use mocha anymore. :p

[dmitriz]

@rstacruz What is better than mocha?

[rstacruz]

I personally prefer tape, but that's just me.

Anyway, IMHO this is most certainly doable. Eslint itself has support for environments defined here: http://eslint.org/docs/user-guide/configuring#specifying-environments. These look particularly useful:

• browser
• worker
• mocha
• ...

[rstacruz]

Also, @feross, this might be worth documenting:

/* eslint-env mocha */

...will consider describe/it/beforeEach/etc as predefined globals.

[dcousens]

I guess if it is basically just a direct pass-through for a common eslint feature, then I'm not against it.

[dcousens]

Though, IMHO /* eslint-env mocha */ (aka, per-file configuration) is a better pattern than package.json defined configuration.

Make the lame things hard, and the bad things impossible

[rstacruz]

yes, i agree. there's also the possibility of this:

{
  "scripts": {
    "lint": "standard 'lib/*.js'; standard 'test/**/*.js' --env mocha"
  }
}

[dcousens]

@rstacruz that I would agree with a lot more than the blanket suggestion.

[dmitriz]

@rstacruz Seems like they require to write this in every single test file:

You always need to require('tape') in test files.

Grows old very fast, imo.

[rstacruz]

@dmitriz: i know this is off tangent in the conversation now, but that's precisely why I like it. It means you have write your test files in idiomatic JavaScript—no fancy test runners. In practice, it means your tests are runnable on their own (node test/foo.js), and perfectly browserifyable (browserify test/index.js). This opens up the opportunity to do a lot of interesting things:

node test.js     # run in node.js
hihat test.js    # run in electron (hihat is browserify-aware)
budo test.js     # run in browser (budo is, too)
browserify test.js | smokestack -b firefox  # run in headless browser

[dmitriz]

@rstacruz I see, interesting, have you seen ava - that looks similar!

[gsklee]

@rstacruz Interesting info ;-)

[feross]

@rstacruz +1 to tape and being unfancy and explicit.

It's not worth saving one line if you break compatibility with everything. All tooling has to add custom support for mocha and know about the exact list of globals that mocha assumes. Not a good tradeoff.

[feross]

That said, we'll support passing through this option to eslint, like we've done for the other options.

[feross]

PR to standard-engine to add support for the --env option: standard/standard-engine#58

Works in package.json:

{
  "standard": {
    "env": {
      "mocha": true
    }
  }
}

And the command line:

standard --env mocha test/*.js

This will be released in standard v6.