Rules for consistent, readable, and valid package.json files. ποΈ
This package requires ESLint >=8:
npm install eslint eslint-plugin-package-json --save-dev
This plugin's recommended configuration enables its rules on **/package.json
files, parsing them with jsonc-eslint-parser
.
In your ESLint configuration file:
import packageJson from "eslint-plugin-package-json";
export default [
// your other ESLint configurations
packageJson.configs.recommended,
];
If you want to override the recommended rules:
import packageJson from "eslint-plugin-package-json";
export default [
// your other ESLint configurations
packageJson.configs.recommended,
{
rules: {
"package-json/valid-package-definition": "off",
},
},
];
See ESLint's Configuration Files guide for details on how to customize your rules and other config settings.
Usage with ESLint's legacy ("eslintrc") format requires also installing jsonc-eslint-parser
:
npm install jsonc-eslint-parser --save-dev
Add an override to your ESLint configuration file that specifies jsonc-eslint-parser
, this plugin, and its recommended rules for your package.json
file:
module.exports = {
overrides: [
{
extends: ["plugin:package-json/legacy-recommended"],
files: ["package.json"],
parser: "jsonc-eslint-parser",
},
],
};
You may also want to individually configure rules. See ESLint's Configure Rules guide for details on how to customize your rules.
module.exports = {
overrides: [
{
extends: ["plugin:package-json/legacy-recommended"],
files: ["package.json"],
parser: "jsonc-eslint-parser",
rules: {
"package-json/valid-package-definition": "error",
},
},
],
};
prettier-plugin-packagejson
is a Prettier plugin that enforces the same package.json
keys ordering as the order-properties
and sort-collections rules with default options.
We recommend using both the Prettier plugin and eslint-plugin-package-json
's recommended configuration.
The default settings don't conflict, and Prettier plugins can quickly fix up ordering in your editor on save and/or as a Git hook.
πΌ Configurations enabled in.
βοΈ Set in the legacy-recommended
configuration.
β
Set in the recommended
configuration.
π§ Automatically fixable by the --fix
CLI option.
π‘ Manually fixable by editor suggestions.
β Deprecated.
NameΒ Β Β Β Β Β Β Β Β Β Β Β Β Β Β Β Β Β Β Β Β Β | Description | πΌ | π§ | π‘ | β |
---|---|---|---|---|---|
no-empty-fields | Reports on unnecessary empty arrays and objects. | βοΈ β | π‘ | ||
no-redundant-files | Prevents adding unnecessary / redundant files. | π‘ | |||
order-properties | Package properties must be declared in standard order | βοΈ β | π§ | ||
repository-shorthand | Enforce either object or shorthand declaration for repository. | βοΈ β | π§ | ||
require-author | Requires the author property to be present. |
||||
require-description | Requires the description property to be present. |
βοΈ β | |||
require-engines | Requires the engines property to be present. |
||||
require-files | Requires the files property to be present. |
||||
require-keywords | Requires the keywords property to be present. |
||||
require-name | Requires the name property to be present. |
βοΈ β | |||
require-type | Requires the type property to be present. |
βοΈ β | |||
require-types | Requires the types property to be present. |
||||
require-version | Requires the version property to be present. |
βοΈ β | |||
restrict-dependency-ranges | Restricts the range of dependencies to allow or disallow specific types of ranges. | π‘ | |||
sort-collections | Dependencies, scripts, and configuration values must be declared in alphabetical order. | βοΈ β | π§ | ||
unique-dependencies | Checks a dependency isn't specified more than once (i.e. in dependencies and devDependencies ) |
βοΈ β | π‘ | ||
valid-author | Enforce that the author field is a valid npm author specification | βοΈ β | |||
valid-bin | Enforce that the bin property is valid. |
βοΈ β | π‘ | ||
valid-local-dependency | Checks existence of local dependencies in the package.json | β | |||
valid-name | Enforce that package names are valid npm package names | βοΈ β | |||
valid-package-definition | Enforce that package.json has all properties required by the npm spec | βοΈ β | |||
valid-repository-directory | Enforce that if repository directory is specified, it matches the path to the package.json file | βοΈ β | π‘ | ||
valid-scripts | Enforce that the scripts property is valid. |
βοΈ β | |||
valid-type | Enforce that the type property is valid. |
βοΈ β | |||
valid-version | Enforce that package versions are valid semver specifiers | βοΈ β |
These rules only run on package.json
files; they will ignore all other files being linted.
They can lint package.json
files at project root and in any subfolder of the project, making this plugin great for monorepos.
We never want to remove things, when we're building them! But the reality is that libraries evolve and deprecations are a fact of life. Following are the different timeframes that we've defined as it relates to deprecating APIs in this project.
When some aspect of our API is going to be deprecated (and eventually removed), it must initially go through an RFC phase. Whoever's motivating the removal of the api, should create an RFC issue explaining the proposal and inviting feedback from the community. That RFC should remain active for at least 6 weeks. The RFC text should make clear what the target date is for closing the RFC. Once the RFC period is over, if the removal is still moving forward, the API(s) should be officially deprecated.
Once an API has been marked as deprecated, it will remain intact for at least 6 months. After 6 months from the date of deprecation, the API is subject to removal.
See .github/CONTRIBUTING.md
, then .github/DEVELOPMENT.md
.
Thanks! π
Many thanks to @zetlen for creating the initial version and core infrastructure of this package! π
π This package was templated with
create-typescript-app
using the Bingo engine.