More parity with eslint/jshint

[es128]

• Moved the typed arrays to builtin (Shouldn't all the typed array classes be moved to builtin? #2) and added Object.prototype methods (toString #3)
• Completed the list of test runner globals
• All sections from eslint's list are now included
• Have not included the following sections from jshint so far (let me know if you'd want them added):
  • browserify - shouldn't the node list should just be used any time this one is desired?
  • shelljs, dojo, mootools, prototypejs
• Added to the browser list anything that was missing when compared with jshint's version of the list

[sindresorhus]

browserify - shouldn't the node list should just be used any time this one is desired?

Does the browserify one have anything different from the node one?

shelljs, dojo, mootools, prototypejs

Agreed.

[es128]

https://github.com/jshint/jshint/blob/493d03d47ce810b8f7464fdb6f1cfd12a0e7f5cb/src/vars.js#L437-L446

The browserify list is a subset of the node's globals.

[sindresorhus]

Yeah, I don't see the point of having a separate browserify option.

[sindresorhus]

Thanks for doing the grunt work on this :D

[lennym]

I just found myself here as a result of pondering on a browserify/commonjs environment for eslint - with just require, module and exports defined. I was wondering if the decision to not include this in this repo was a firm one, because I personally would find it very useful to be able to eslint browserify'ed code without having to also add all of the node globals.

[es128]

@lennym so in this scenario you want to be able to reuse the other identifier names used as node globals for other purposes and have the linter respond accordingly? Doesn't seem like a great practice to follow. Can you demonstrate a use case where this would make sense?

[lennym]

I'm running eslint over code which is run in browser, but uses browserify. Thus I want require and module to be allowed globals, but not all the additional things which adding node as an env also allows.

[es128]

In case one accidentally uses a node global forgetting where this code is meant to be run? I thought browserify's transforms already took care of this.

[lennym]

Yes, I had a play and it seems that you're right. Browserify does seem to "just work" as best as it can with node globals.

I still feel like setting env node: true in the eslintrc for files I know aren't going to run in a node env is some severe misdirection, but at least I know it's not going to allow anything which will bring down my app now.