Add `allow` option to `no-nodejs-modules`

[ljharb]

The no-nodejs-modules rule is very useful, but some modules are fine to import - like events - due to a good browserify shim.

I'd like the ability to add exceptions to this rule.

[jfmengels]

Wouldn't be very hard to implement. But does this occur very often? If not, a eslint-disable comment could be the best option.

[benmosher]

I had the same initial gut reaction as @jfmengels, though that said I can imagine making a browserify shared config with this rule configured with a default whitelist. (crypto comes to mind as well as one that works fine in the browser.)

Also, I'd move to call the option whitelist, barring precedent from other rules (in this plugin or elsewhere).

Would be an easy PR for someone. @jfmengels do you think it hurts to have this?

[jfmengels]

Just getting the feeling that for a lot of rules there are a lot of requests to have exceptions. It's a recurring theme.
But no, I think it's fine here.

👍 for whitelist

[benmosher]

Yeah, I am getting that feeling too, in general.

This case is explicit, pragmatic, and obvious, though.

I can imagine one could argue for an eslint-plugin-browserify to handle this, maybe, but that would be on the pedantic side.

(linked because a quick web search found it to exist, by the law of npm that there is an npm package for every combination of two popular projects that support plugins, lol. 😎)

[benmosher]

Updated title to match discussion, @ljharb feel free to voice disagreement, just wanted to make sure possible PR submitters don't miss the discussion.

[ljharb]

I'd prefer a more neutral term that lacks the connotation of "whitelist".

[benmosher]

Fair enough. allow?

[ljharb]

Sounds great! Fwiw, this isn't just for browserify, anyone who'd set up a custom alias for bundling, in webpacking as well, may still want this ability.