mysticatea/eslint-plugin-node

Additional ESLint's rules for Node.js

This project has been no longer maintained. Please consider to use https://github.com/eslint-community/eslint-plugin-n.

eslint-plugin-node

Additional ESLint's rules for Node.js

💿 Install & Usage

$ npm install --save-dev eslint eslint-plugin-node

• Requires Node.js >=8.10.0
• Requires ESLint >=5.16.0

Note: It recommends a use of the "engines" field of package.json. The "engines" field is used by node/no-unsupported-features/* rules.

.eslintrc.json (An example)

{
    "extends": [
        "eslint:recommended",
        "plugin:node/recommended"
    ],
    "parserOptions": {
        // Only ESLint 6.2.0 and later support ES2020.
        "ecmaVersion": 2020
    },
    "rules": {
        "node/exports-style": ["error", "module.exports"],
        "node/file-extension-in-import": ["error", "always"],
        "node/prefer-global/buffer": ["error", "always"],
        "node/prefer-global/console": ["error", "always"],
        "node/prefer-global/process": ["error", "always"],
        "node/prefer-global/url-search-params": ["error", "always"],
        "node/prefer-global/url": ["error", "always"],
        "node/prefer-promises/dns": "error",
        "node/prefer-promises/fs": "error"
    }
}

package.json (An example)

{
    "name": "your-module",
    "version": "1.0.0",
    "type": "commonjs",
    "engines": {
        "node": ">=8.10.0"
    }
}

📖 Rules

• ⭐️ - the mark of recommended rules.
• ✒️ - the mark of fixable rules.

Possible Errors

Rule ID	Description
node/handle-callback-err	require error handling in callbacks
node/no-callback-literal	ensure Node.js-style error-first callback pattern is followed
node/no-exports-assign	disallow the assignment to exports	⭐️
node/no-extraneous-import	disallow import declarations which import extraneous modules	⭐️
node/no-extraneous-require	disallow require() expressions which import extraneous modules	⭐️
node/no-missing-import	disallow import declarations which import non-existence modules	⭐️
node/no-missing-require	disallow require() expressions which import non-existence modules	⭐️
node/no-new-require	disallow new operators with calls to require
node/no-path-concat	disallow string concatenation with __dirname and __filename
node/no-process-exit	disallow the use of process.exit()
node/no-unpublished-bin	disallow bin files that npm ignores	⭐️
node/no-unpublished-import	disallow import declarations which import private modules	⭐️
node/no-unpublished-require	disallow require() expressions which import private modules	⭐️
node/no-unsupported-features/es-builtins	disallow unsupported ECMAScript built-ins on the specified version	⭐️
node/no-unsupported-features/es-syntax	disallow unsupported ECMAScript syntax on the specified version	⭐️
node/no-unsupported-features/node-builtins	disallow unsupported Node.js built-in APIs on the specified version	⭐️
node/process-exit-as-throw	make process.exit() expressions the same code path as throw	⭐️
node/shebang	suggest correct usage of shebang	⭐️✒️

Best Practices

Rule ID	Description
node/no-deprecated-api	disallow deprecated APIs	⭐️

Stylistic Issues

Rule ID	Description
node/callback-return	require return statements after callbacks
node/exports-style	enforce either module.exports or exports
node/file-extension-in-import	enforce the style of file extensions in import declarations	✒️
node/global-require	require require() calls to be placed at top-level module scope
node/no-mixed-requires	disallow require calls to be mixed with regular variable declarations
node/no-process-env	disallow the use of process.env
node/no-restricted-import	disallow specified modules when loaded by import declarations
node/no-restricted-require	disallow specified modules when loaded by require
node/no-sync	disallow synchronous methods
node/prefer-global/buffer	enforce either Buffer or require("buffer").Buffer
node/prefer-global/console	enforce either console or require("console")
node/prefer-global/process	enforce either process or require("process")
node/prefer-global/text-decoder	enforce either TextDecoder or require("util").TextDecoder
node/prefer-global/text-encoder	enforce either TextEncoder or require("util").TextEncoder
node/prefer-global/url-search-params	enforce either URLSearchParams or require("url").URLSearchParams
node/prefer-global/url	enforce either URL or require("url").URL
node/prefer-promises/dns	enforce require("dns").promises
node/prefer-promises/fs	enforce require("fs").promises

Deprecated rules

These rules have been deprecated in accordance with the deprecation policy, and replaced by newer rules:

Rule ID	Replaced by
node/no-hide-core-modules	(nothing)
node/no-unsupported-features	node/no-unsupported-features/es-syntax and node/no-unsupported-features/es-builtins

🔧 Configs

This plugin provides three configs:

• plugin:node/recommended considers both CommonJS and ES Modules. If "type":"module" field existed in package.json then it considers files as ES Modules. Otherwise it considers files as CommonJS. In addition, it considers *.mjs files as ES Modules and *.cjs files as CommonJS.
• plugin:node/recommended-module considers all files as ES Modules.
• plugin:node/recommended-script considers all files as CommonJS.

Those preset config:

• enable no-process-exit rule because the official document does not recommend a use of process.exit().
• enable plugin rules which are given ⭐ in the above table.
• add {ecmaVersion: 2019} and etc into parserOptions.
• add proper globals into globals.
• add this plugin into plugins.

👫 FAQ

• Q: The no-missing-import / no-missing-require rules don't work with nested folders in SublimeLinter-eslint
• A: See context.getFilename() in rule returns relative path in the SublimeLinter-eslint FAQ.

🚥 Semantic Versioning Policy

eslint-plugin-node follows semantic versioning and ESLint's Semantic Versioning Policy.

• Patch release (intended to not break your lint build)
  • A bug fix in a rule that results in it reporting fewer errors.
  • Improvements to documentation.
  • Non-user-facing changes such as refactoring code, adding, deleting, or modifying tests, and increasing test coverage.
  • Re-releasing after a failed release (i.e., publishing a release that doesn't work for anyone).
• Minor release (might break your lint build)
  • A bug fix in a rule that results in it reporting more errors.
  • A new rule is created.
  • A new option to an existing rule is created.
  • An existing rule is deprecated.
• Major release (likely to break your lint build)
  • A support for old Node version is dropped.
  • A support for old ESLint version is dropped.
  • An existing rule is changed in it reporting more errors.
  • An existing rule is removed.
  • An existing option of a rule is removed.
  • An existing config is updated.

📰 Changelog

• GitHub Releases

❤️ Contributing

Welcome contributing!

Please use GitHub's Issues/PRs.

Development Tools

• npm test runs tests and measures coverage.
• npm run coverage shows the coverage result of npm test command.
• npm run clean removes the coverage result of npm test command.

eslint-plugin-node's Issues

Read required Node.js version from project package.json

For the no-unsupported-features rule. I have a shareable config and I don't want to manually specify the required Node.js version for each project. That information is already available in the engines field in package.json.

You could use read-pkg-up.

`no-unsupported-features` "blockScopedFunctions" misbehaving?

source

I get an error from a top level function definition:

// whatever.js
function whatever() { } // Block-Scoped Functions are not supported yet on Node v0.10  node/no-unsupported-features

Semantic Versioning Policy

ESLint declared Semantic Versioning Policy.
This plugin would declare to follow that.

Rule Proposal: `no-deprecated-api`

Node API has the stability index: https://nodejs.org/api/documentation.html#documentation_stability_index
This rule warns using of lower stability API than a specific value.

{
    // will warn API of less than 2 (experimental and deprecated).
    "no-unstable-api": [2, {"stability": 2}]
}

shebang doesn't recognize additional CLI flags

I'm using [email protected] and my pseudo .eslintrc.yml file is:

extends:
  - eslint:recommended
  - plugin:node/recommended

plugins:
  - node

rules:
  node/no-unpublished-bin: error

When I run $ eslint ., I get the following error:

> eslint .


/Users/pdehaan/dev/github/mozilla/observatory-cli/index.js
  3:1  error  This file needs shebang "#!/usr/bin/env node"  node/shebang

✖ 1 problem (1 error, 0 warnings)

But the first line of my /index.js file is:

#!/usr/bin/env node --harmony

It looks like the node/shebang rule may be looking for an exact match of #!/usr/bin/env node and isn't liking the awkward use of the --harmony flag at the end.

Removing the --harmony from the shebang in /index.js works as expected.

Switch eslint-config to mine.

eslint-config-eslint is not working.

Add prerelease versions to peerDependencies

">=1.0.0" does not match 2.0.0-beta.3.

Clarify `node/no-unpublished-import` and `files` in `package.json`.

I have babel and this structure:

src/index.js - my code, which published
src/__tests__/index-test.js - file contains tests, which exclude from published

index.js compiled in dist directory, using command babel src --out-dir dist --ignore /__tests__/.

In package.json contains (so as not publish tests.):

"files": [
  "dist",
  "!**/__tests__"
],

But i got error if can try import packages from devDependencies in src/__tests__/index-test.js:

/path/to/packege/src/__tests__/index-test.js
  4:18  error  "ava" is not published  node/no-unpublished-import

I can try convertPath options but still getting an error. Based on the description, I like to do everything right.

Make `shebang` rule fixable

I will make shebang rule supporting --fix.

`no-unpublished-*` false positive.

Those rules are not handling the "files" field of package.json correctly.
"files": ["lib"] is matching tests/lib/foo.js currently.

Disallow all synchronous methods

This would be a great addition to this plugin.

Support webpack loaders or add options for this

require('bundle!./bootlint-loader')

Add Node 6 to Travis tests

`no-missing-require` does not work on ESLint v2.0.0

http://eslint.org/docs/2.0.0/user-guide/migrating-to-2.0.0#scope-analysis-changes

Option Proposal: "allow" for no-{missing,unpublished}-{require,import}

We can use this option to allow additional embedded modules.
e.g.

/*eslint no-missing-require: [2, {"allow": ["electron"]}]*/

const {app, dialog} = require("electron");

Subclassing and static methods support in `no-unsupported-features`

Rethink the option of `shebang` rule.

New Rule: disallow a use of both `exports.foo` and `module.exports` at same time

By default, exports is the same instance as module.exports.
But if you write module.exports = {}, the instance of those variables gets different.

This rule should warn the following code:

module.exports = {
    foo() {}
}

// `bar` is not exported.
exports.bar = function() {
}

bug

{
    "rules": {
        "node/no-missing-require": [2, {
            "allowModules": ["jquery.cookie"]
        }]
    }
}

Output

Configuration for rule "node/no-missing-require" is invalid:
    Value "jquery.cookie" pattern mismatch.

exports-style: Invalid docs

Hi,

There is a little mistake in exports-style rule docs: https://github.com/mysticatea/eslint-plugin-node/blob/master/docs/rules/exports-style.md#options

Correct name of the rule is node/exports-style and this should be used in rules configuration and in examples.

Regards

node/no-unsupported-features has false negative for Node 4

Node 4 has supported Object Literal Enhancements.
But I realized that it's not completely.

"use strict"

let get = 1
let obj = {get}

let set = 1
let obj2 = {set}

This code is valid in the language spec, but Node 4 throws syntax errors at {get} and {set}.
Maybe Node 4 is confused with getter/setter syntax.
node/no-unsupported-features rules must warn those.

Update to enforce node.js core linting rules

see https://github.com/nodejs/node/blob/master/.eslintrc

Since this is named node maybe you can update it to use the node.js core lint rules?

Support for harmony flags?

I'm not sure how you'd go about this because package.json doesn't have a way of marking harmony mode as required, and it may not be a big enough necesity to warrant the difficulty, particularly moving forward as node support for ES6/7 grows.

Make `shebang` rule supporting Unicode BOM.

Related: eslint/eslint#4878

If there is BOM, shebang will not work.

New Rule: `no-sloppy-block-bindings`

Node.js 4 and 5 are supporting block bindings only in strict mode.
So if block bindings are used in sloppy mode, this rule reports those.

Remove prerelease versions from `peerDependencies`

After #24.
After ESLint v2.0.0 was released.

This is the last breaking change for v1.0.0.

New Rule: no-unpublished-bin

This rule will warn the whole file which is unpublished and which exists in bin field of package.json.

Example:

package.json

{
    "bin": "bin/foo.js",
    "files": ["lib"]
}

In this case, bin/foo.js is warned.
bin/foo.js is unpublished but is specified as bin scripts.
This is going to cause installation failure (failed to make symlink for the command).

Issue with `no-unpublished-require` and `devDependencies` modules

If I use this code:

const test = require("ava")

With the rule:

'node/no-unpublished-require': 'error',

And AVA is in my package.json:

  "devDependencies": {
    "ava": "^0.15.1",
  },

I get the warning:

1:22  error  "ava" is not published  node/no-unpublished-require

The rule readme says:

"...If the file require is written is not published then it's also OK that "devDependencies" field of package.json includes the module."

Am I correct in reading that this should not error if the module is in devDependencies?

Rule request: no-missing-dependency

The idea of this rule is to disallow require/import of a dependency not listed explicitly in package.json.

The rule would be useful when using npm 3, since npm 3 auto-dedupes and dependencies get installed in a flat form. the app have the posibility to require a module that is not a explicit dependency, this rule would prevent that scenario

Thoughts?

no-deprecated-api throws a TypeError with global assignment

Hi!

I'm using:

• Node v6.9.1
• [email protected]
• [email protected]
• .eslintrc.yml:

  rules:
    node/no-deprecated-api: error
  plugins:
    - node
  env:
    node: true
  

• foo.js:

  fs = require('fs');

When I run node_modules/.bin/eslint foo.js, a TypeError is thrown:

TypeError: Cannot read property 'references' of null
    at eachReadReferences (path/to/node_modules/eslint-plugin-node/lib/rules/no-deprecated-api.js:146:13)
    at checkVariable (path/to/node_modules/eslint-plugin-node/lib/rules/no-deprecated-api.js:353:9)
    at checkDestructuring (path/to/node_modules/eslint-plugin-node/lib/rules/no-deprecated-api.js:249:17)
    at checkProperties (path/to/node_modules/eslint-plugin-node/lib/rules/no-deprecated-api.js:323:21)
    at path/to/node_modules/eslint-plugin-node/lib/rules/no-deprecated-api.js:431:29
    at Array.forEach (native)
    at eachReadReferences (path/to/node_modules/eslint-plugin-node/lib/rules/no-deprecated-api.js:146:49)
    at checkCommonJsModules (path/to/node_modules/eslint-plugin-node/lib/rules/no-deprecated-api.js:416:13)
    at EventEmitter.Program:exit (path/to/node_modules/eslint-plugin-node/lib/rules/no-deprecated-api.js:486:13)
    at emitOne (events.js:96:13)

Allows `this` in `EventEmitter`'s callbacks (`no-invalid-this`)

Bug: no-deprecated-api reports invalid deprecation

Running node v4 with the no-deprecated-api enabled causes the following error report:

'Buffer' constructor was deprecated since v6. Use 'Buffer.alloc()' or 'Buffer.from()' instead node/no-deprecated-api

So:

• it's reporting a deprecation for a version later than the version I'm using
• most importantly, the alternative api has not been implemented in the version I'm using

This is applicable to other Buffer api deprecations in node 6.

By default, we should compare versions and not report that an api has been deprecated until the user is using a version in which the api has actually been deprecated. (I think it's a good idea to enable forcing the warnings so you can test forward-compatibility, though.)

`tryExtensions` option for `no-missing-*` and `no-unpublish-*`

Spawned from #12.
Thank you @AprilArcus!

Running eslint with this rule in gulp return `Error: Cannot find module 'package.json'`

Looks like in get-package-json.js:

startPath = 'gulpfile.babel.js'
path.join('.', 'package.json'); => 'package.json'

So it try to require 'package.json' instead of './package.json'

Sorry no time today to do a pull request :(

Separate static method linting from no-unsupported-features rule

It would be cool to be able to lint against inappropriate use of unsupported static methods separately from the other unsupported syntax features when using e.g. Babel without the polyfill and targeting older versions of node.

no-unsupported-features for Node 6

update no-deprecated-api rule for Node 7

• require("os").tmpDir has been deprecated nodejs/node#6739.
• punycode module has been deprecated nodejs/node#7941.
• Intl.v8BreakIterator has been deprecated nodejs/node#8908.
• It's lacking the check for undocumented properties:
  • properties of require("readline") nodejs/node#6423
    • .codePointAt
    • .getStringWidth
    • .isFullWidthCodePoint
    • .stripVTControlCharacters
  • process.EventEmitter nodejs/node#6862.
  • properties of require("module") nodejs/node#8575
    • .requireRepl
    • .Module.requireRepl
• Notes of known limitations:
  • require("repl").REPLServer.prototype.convertToContext nodejs/node#7829

no-deprecated-api: Configure which APIs to prevent

I'd like to add this plugin to standard so we can use the no-deprecated-api rule. But I don't want to prevent people from using APIs that were deprecated in v7, for example, because that's an unstable version, and things may be un-deprecated.

Could we add a way to configure the rule to select which APIs to prevent? Manually specifying the individual rules is fine, or we could base it on the version that the feature was deprecated in. So I could say something like "no-deprecated-api": ["error", 4] or "no-deprecated-api": ["error", 6].

no-missing-{import,require} rule not handling index.js file when requiring a directory

my rules are the following:

"node/no-missing-import": 2,
"node/no-missing-require": 2,
"node/no-unpublished-import": 2,
"node/no-unpublished-require": 2,
"node/no-unsupported-features": [2, {"version": 4}],
"node/shebang": 2

i'm requiring two directories ./fileSchemas and ./utils/logger both directories have a index.js inside but eslint-plugin-node reports an error.

according to node docs this is a valid require when dealing with directories.

Plan to drop supports Node 0.10, 0.12 and ESLint 2.x

https://github.com/nodejs/LTS#readme

I will drop supports for both 0.10 and 0.12 at the end of 2016.

At the same time, I will drop supports for ESLint 2.x.
ESLint 2.x is supporting Node 0.10 and 0.12. I cannot use ES6 features in this codebase if I don't drop supports for ESLint 2.x.

Drop supports for ESLint 1.x

Within a few weeks, ESLint 3.0.0 will be released.
After that, I'm going to drop supports for ESLint 1.x.

Of course, it's a major release.

Add webpack-resolver

Hey, awesome plugin!

Though, it doesn't work properly when requires are resolved by webpack. In eslint-plugin-import they use a separate resolver for cases like that. Perhaps something similar can be added for this plugin?

I saw you already ignore paths preceded by !-symbol, but it doesn't work for features like aliases and in general looks more like a patch than a solution.

Thanks

Upgrade minimatch to 3.0.2

https://nodesecurity.io/advisories/minimatch_regular-expression-denial-of-service

Should no-unsupported-features disable the prefer-rest-params rule on Node.js v4?

I am trying to use this in combination with eslint-config-google. My package.json specifies engines.node >= 4.

The google config enables the prefer-rest-params rule, and that does work on node v4 with --harmony, but not otherwise.

My expectation was that this plugin/config would override the google one, but that didn't happen, and I have to override it myself in my .eslintrc.js file.

Is that a bug in this plugin, or just incorrect expectations on my part?

no-unsupported-features should handle ES2016, ES2017 features.

• syntax
  • exponential operators (**).
  • trailing commas of functions.
  • async functions and await expressions.
• runtime
  • Object.values
  • Object.entries
  • Object.getOwnPropertyDescriptors
  • class extends null

I'm planning to do this when Node 7 is released.

Separate checking publish from `no-missing-*`

Provide the config plugin:node/recommended

The version of ESLint you are using.

• 2.12.0

The problem you want to solve.

• To provide the choice of the configuration by oneself or the default recommended.

Your take on the correct solution to problem.

• To provide the eslint-plugin-node's recommended configuration like yannickcr/eslint-plugin-react's recommended config.

---

This issue is just a proposal.
I'd like to discuss with author @mysticatea .

Thanks.

remove fs.existsSync from no-deprecated-api

https://nodejs.org/en/blog/release/v6.8.0/

`no-missing-require` doesn't work in Atom (linter-eslint)

In Atom with linter-eslint, no-missing-require always reports an error "x" is not found for npm packages and local files. Passed for core modules.

All versions are latest stable:

• Mac OS X 10.11.4
• Atom v1.6.0
• ESLint v2.5.1
• linter v1.11.1
• linter-eslint v7.1.3

New Rule: `restrict-syntax`

This rule reports unusable syntax and global variables in Node.js of a specified version.

{
    "node/restrict-syntax": [2, 4],    // Node.js 4.x (Argon)
    "node/restrict-syntax": [2, 5]     // Node.js 5.x
}

This rule is used with {env: {es6: true}}

Further Reading: http://kangax.github.io/compat-table/es6/