Automatically set environment for common test frameworks

[brandonhorst]

I use mocha, and standard complains about the undeclared variables (like describe, it, and before) that it uses. Of course, I can add

/*eslint-env mocha */

but that seems like something that could be handled by standard. Perhaps inspecting package.json to look at dependencies and directories.test, or just making some common guesses.

Perhaps this is outside of the scope, but it certainly would make me feel more standard if I could just arrange my projects in a specific way and ignore the linter directives entirely.

[jprichardson]

The solution is to just do this:

/* global beforeEach, describe, it */

See this for an example: https://github.com/jprichardson/node-cfs/blob/master/test.js

[brandonhorst]

I understand that. As I mentioned, /*eslint-env mocha */ does the same thing. I just don't want to have to put that directive.

My enhancement request for standard to handle it automatically.

[yoshuawuyts]

With mocha you can't do:

$ node test.js

To me it feels that standard should catch this and warn about non standard globals being used.

[dcousens]

My enhancement request for standard to handle it automatically.

How would you recommend we do that?

To me it feels that standard should catch this and warn about non standard globals being used.

There is no difference between a non-standard global and a undefined variable.

[brandonhorst]

Here is some weird pseudocode.

var info = findup package.json
var environment = 'node browser'
if dependencies contains 'mocha' { environment += ' mocha'}
if dependencies contains 'jasmine' { environment += ' jasmine'}
for file in (info.directories.test || './test' exists || './spec' exists) {
    lint with environment
}
for other files {lint with environment = 'node browser'}

findup

I fully understand that these globals are nonstandard/undefined (and it's kind of weird that mocha/jasmine /etc are implemented this way, frankly). But standard could be smart enough to handle them.

[jprichardson]

You're right, it could. But I think it's more a question of "should". The
thing is, that in the context of style (standard), when looking at a source
file, you shouldn't have to depend upon another file like package.json to
communicate additional information. Also, It opens up a gray area... where
does one draw the line? Yeah, mocha and jasmine are popular now, but what
if another tool comes along and introduces its own set of globals? When
looking at a source file, if one just declares their globals in a comment,
that's good enough, as all of the information is contained in that one
single file.

On Wednesday, February 4, 2015, Brandon Horst notifications@github.com
wrote:

Here is some weird pseudocode.

var info = findup package.json
var environment = 'node browser'
if dependencies contains 'mocha' { environment += ' mocha'}
if dependencies contains 'jasmine' { environment += ' jasmine'}
for file in (info.directories.test || './test' exists || './spec' exists) {
lint with environment
}
for other files {lint with environment = 'node browser'}

findup https://www.npmjs.com/package/findup

I fully understand that these globals are nonstandard/undefined (and it's
kind of weird that mocha/jasmine /etc are implemented this way, frankly).
But standard could be smart enough to handle them.

—
Reply to this email directly or view it on GitHub
#18 (comment).

Simple & Secure Bitcoin Wallet: https://www.coinbolt.com
Bitcoin / JavaScript: http://cryptocoinjs.com
Follow me on Twitter: http://twitter.com/jprichardson

[kytwb]

@jprichardson couldn't agree more.

[feross]

Closing this for now, as the consensus seems to be that it's simplest to have mocha users just define globals in a comment.