eslint-plugin-package-json

Rules for consistent, readable, and valid package.json files. 🗂️

Installation

This package requires ESLint >=8:

npm install eslint eslint-plugin-package-json --save-dev

Usage

Flat Config

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.

Legacy Config

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",
            },
        },
    ],
};

Usage Alongside Prettier

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.

Supported Rules

💼 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.

Deprecation Policy

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.

RFC Timeframe (6 weeks)

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.

Removal Timeframe (6 months)

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.

Development

See .github/CONTRIBUTING.md, then .github/DEVELOPMENT.md. Thanks! 🗂

Contributors

_Alan 🐛 💻	_{Andreas Lindberg} 🐛	_{Andrew Kazakov} 🐛 💻	_{Anton Khitrenovich} 🤔	_{Azat S.} 🤔 💻	_{Curtis Jewell} 🤔	_{David LJ} 📖
_Eli 🤔	_Heggria 🤔	_James 💻	_{James Zetlen} 💻 🐛 📖 🚇 🚧 🔧	_{Jesús Leganés-Combarro} 💻	_{Josh Goldberg ✨} 🔧 🐛 💻 🚇 📖 🚧 🤔 🖋 📆	_{Kendall Gassner} 💻 🚧
_{Kristjan ESPERANTO} 🤔 🐛 💻	_{Mathias Schreck} 🤔	_{Michael "Mike" Ferris} 💻	_{Nick Schonning} 💻	_Pavel 🤔 🔧 📖 💻 🐛	_Sasial 💻	_Stephen 💻
_{Stephen Zhou} 🐛 💻 🤔 📖	_{Yosuke Ota} 🐛 💻	_b3rnhard 🐛	_chouchouji 💻	_{michael faith} 🚇 💻 🚧 🤔 🐛 🔧 📖	_roottool 💻	_{sunnytsang1998} 🐛