Add eslint-plugin-node

[pvdlg]

Fixes #123

Add the following rules:

Rule ID	Description
no-unpublished-bin	Disallow 'bin' files which are ignored by npm
no-unpublished-import	Disallow import declarations of private things
no-unpublished-require	Disallow require() expressions of private things
process-exit-as-throw	Make process.exit() expressions the same code path as throw
no-deprecated-api	Disallow unsupported ECMAScript features on the specified version
exports-style	Enforce either module.exports or exports

The other rules provided are disabled for the following reasons:

Rule ID	Reason for disabling
no-extraneous-import	Redundant with import/no-extraneous-dependencies
no-extraneous-require	Redundant with import/no-extraneous-dependencies
no-missing-import	Redundant with import/no-unresolved
no-missing-require	Redundant with import/no-unresolved
no-unsupported-features	Doesn't allow to exclude compiled sources
shebang	Doesn't exclude scripts executed with node but not referenced in "bin" (i.e main.js)
exports-style	Too restrictive, forces to use either modules.exports or exports but not both

Let me know if I should make changes in the rules enabled/disabled or in the configuration.

[sindresorhus]

no-unsupported-features | Doesn't allow to exclude compiled sources
-- | --

Can you open an issue on eslint-plugin-node about supporting this?

shebang | Doesn't exclude scripts executed with node but not referenced in "bin" (i.e main.js)
-- | --

This too.

exports-style | Too restrictive, forces to use either modules.exports or exports but not both
-- | --

And this.

[sindresorhus]

Include electron and atom in the allowModules option: https://github.com/mysticatea/eslint-plugin-node/blob/master/docs/rules/no-unpublished-import.md#allowmodules For ease of use with Electron and Atom.

[pvdlg]

Done!

[sindresorhus]

Same as above.

[pvdlg]

Done!

[pvdlg]

no-unsupported-features | Doesn't allow to exclude compiled sources

mysticatea/eslint-plugin-node#97

shebang | Doesn't exclude scripts executed with node but not referenced in "bin" (i.e main.js)

mysticatea/eslint-plugin-node#96

exports-style | Too restrictive, forces to use either modules.exports or exports but not both

I first though it was possible to use both modules.exports and exports in the same project as long as it's consistent in the same js file. After more tests it turns out I was wrong.
Using export style that are consistent within each file but inconsistent across the project does create the issue described in the rule.
So I went ahead and enabled the rule

[pvdlg]

@sindresorhus per this comment we could use the override feature to disable those rules for certain files.

In xo we could by default enable the shebang rule only for the files in the bin property of the package.json.

Regarding no-unsupported-features we could enable it only for certain files, but I don't know if there is a good default setting. We can either:

• keep it disabled and let users enable it if they want to
• Enable it and exclude ava files by default and let the users configure the overrides property to exclude more
• Add a new property in xo called something like compiledSources that will allow to define an Array of globs. And we could use it to disable certain rules for files that match.

What's your thoughts ?
Also I'm not sure that should be part of this PR or if it should be implemented in a following one.

[sindresorhus]

In xo we could by default enable the shebang rule only for the files in the bin property of the package.json.

Yes, let's wait an see the outcome of mysticatea/eslint-plugin-node#96

Regarding no-unsupported-features we could enable it only for certain files, but I don't know if there is a good default setting. We can either:

Let's keep it disabled. I don't want lots of complication for something that is not super useful with latest Node.js, as there are not that many commonly used unsupported features.

[sindresorhus]

Can you link to mysticatea/eslint-plugin-node#96 ?

[pvdlg]

Done

[sindresorhus]

I don't think allowBatchAssign should be true. It's not a good pattern.

[pvdlg]

Done

[pvdlg]

Let's keep it disabled. I don't want lots of complication for something that is not super useful with latest Node.js, as there are not that many commonly used unsupported features.

This is something we can implement within the scope of #266

[sindresorhus]

This is something we can implement within the scope of #266

Agreed :)

[sindresorhus]

Great! Thank you 🙌

Would you be interested in joining the project? You have done some high-quality contributions :)

[pvdlg]

I'll take a stab at #266 sometime (in a weeks I guess).

[pvdlg]

Would you be interested in joining the project? You done some high-quality contributions :)

Absolutely !