@erboladaiorg/voluptatibus-iusto
forked from @erboladaiorg/voluptatibus-iustoode v11.1.0. as the original repository seems no longer maintained.
Additional ESLint rules for Node.js
π¨ Playground
online-playground
πΏ Install & Usage
npm install --save-dev eslint @erboladaiorg/voluptatibus-iusto
Version | Supported Node.js | Supported ESLint Version | Status |
---|
17.x | ^18.18.0 || ^20.9.0 || >=21.1.0 | >=8.23.0 | πββοΈactively maintained |
16.x | >=16.0.0 | >=7.0.0 | β οΈEOL |
15.x | >=12.22.0 | >=7.0.0 | β οΈEOL |
Note: It recommends a use of the "engines" field of package.json. The "engines" field is used by n/no-unsupported-features/*
rules.
{
"extends": ["eslint:recommended", "plugin:n/recommended"],
"parserOptions": {
"ecmaVersion": 2021
},
"rules": {
"n/exports-style": ["error", "module.exports"]
}
}
const nodePlugin = require("@erboladaiorg/voluptatibus-iusto")
module.exports = [
nodePlugin.configs["flat/recommended-script"],
{
rules: {
"n/exports-style": ["error", "module.exports"]
}
}
]
package.json (An example)
{
"name": "your-module",
"version": "1.0.0",
"type": "commonjs",
"engines": {
"node": ">=8.10.0"
}
}
Configured Node.js version range
The rules get the supported Node.js version range from the following, falling back to the next if unspecified:
- Rule configuration
version
- ESLint shared setting
node.version
package.json
[engines
] field>=16.0.0
If you omit the [engines] field, this rule chooses >=16.0.0
as the configured Node.js version since 16
is the maintained lts (see also Node.js Release Working Group).
For Node.js packages, using the [engines
] field is recommended because it's the official way to indicate support:
{
"name": "your-module",
"version": "1.0.0",
"engines": {
"node": ">=16.0.0"
}
}
For Shareable Configs or packages with a different development environment (e.g. pre-compiled, web package, etc.), you can configure ESLint with settings.node.version
to specify support.
π Rules
πΌ Configurations enabled in.
βοΈ Set in the flat/recommended
configuration.
π’ Set in the flat/recommended-module
configuration.
β
Set in the flat/recommended-script
configuration.
βοΈ Set in the recommended
configuration.
π’ Set in the recommended-module
configuration.
β
Set in the recommended-script
configuration.
π§ Automatically fixable by the --fix
CLI option.
β Deprecated.
π§ Configs
| Name |
---|
π | flat/mixed-esm-and-cjs |
βοΈ | flat/recommended |
π’ | flat/recommended-module |
β
| flat/recommended-script |
βοΈ | recommended |
π’ | recommended-module |
β
| recommended-script |
About each config:
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.recommended-module
: Considers all files as ES Modules.recommended-script
: Considers all files as CommonJS.
These preset configs:
- enable no-process-exit rule because the official document does not recommend a use of
process.exit()
. - enable plugin rules indicated by emojis in the rules table.
- add
{ecmaVersion: 2021}
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.
-
Q: How to use the flat eslint config with mixed commonjs and es modules?
-
A: You can use the new exported flat config flat/mixed-esm-and-cjs
, an example:
const nodePlugin = require("@erboladaiorg/voluptatibus-iusto");
module.exports = [
...nodePlugin.configs["flat/mixed-esm-and-cjs"],
{
rules: {
"n/exports-style": ["error", "module.exports"],
},
},
]
π₯ Semantic Versioning Policy
@erboladaiorg/voluptatibus-iusto
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.
Deprecated rules follow ESLint's deprecation policy.
π° Changelog
β€οΈ 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.