eslint-plugin-package-json

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

Installation

This package requires ESLint >=8:

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

Usage

$3

This plugin's recommended configuration enables its rules on **/package.json files, parsing them with jsonc-eslint-parser.

`ts
// eslint.config.ts
import packageJson from "eslint-plugin-package-json";
import { defineConfig } from "eslint/config";

export default defineConfig([
// your other ESLint configurations
packageJson.configs.recommended,
]);
`

If you want to override the recommended rules:

`ts
// eslint.config.ts
import packageJson from "eslint-plugin-package-json";
import { defineConfig } from "eslint/config";

export default defineConfig([
// your other ESLint configurations
{
extends: [packageJson.configs.recommended],
files: ["package.json"],
rules: {
"package-json/require-author": "error",
},
},
]);
`

See ESLint's _Configuration Files_ guide for details on how to customize your rules and other config settings.

$3

The recommended-publishable configuration has everything in it from the standard recommended config, with some additional rules added that are geared towards packages that are intended to be published.

`ts
// eslint.config.ts
import packageJson from "eslint-plugin-package-json";
import { defineConfig } from "eslint/config";

export default defineConfig([
// your other ESLint configurations
packageJson.configs["recommended-publishable"],
]);
`

$3

The stylistic configuration sets up the parser and files similar to the recommended config, but includes rules that are more opinionated about the style of a package.json.
This can be used in addition to the recommended config, or on its own.

`ts
// eslint.config.ts
import packageJson from "eslint-plugin-package-json";
import { defineConfig } from "eslint/config";

export default defineConfig([
// your other ESLint configurations
packageJson.configs.recommended, // or packageJson.configs["recommended-publishable"]
packageJson.configs.stylistic,
]);
`

$3

Usage with ESLint's legacy ("eslintrc") format requires also installing jsonc-eslint-parser:

`shell
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:

`ts
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.

`ts
module.exports = {
overrides: [
{
extends: ["plugin:package-json/legacy-recommended"],
files: ["package.json"],
parser: "jsonc-eslint-parser",
rules: {
"package-json/valid-package-definition": "error",
},
},
],
};
`

$3

Some rules can be configured in ESLint shared settings.
You can set them in settings.packageJson in an ESLint flat config.

Example:

`ts
// eslint.config.ts
import packageJson from "eslint-plugin-package-json";
import { defineConfig } from "eslint/config";

export default defineConfig({
plugins: {
"package-json": packageJson,
},
rules: {
// description won't be required in package.json with "private": true
"package-json/require-description": "error",
},
settings: {
packageJson: {
enforceForPrivate: false,
},
},
});
`

#### enforceForPrivate

- Type: boolean
- Default: [see below]

When a package.json file has a "private": true field, it indicates that the package will not be published to npm (or another online registry).
Some fields that are nice to have in public packages become less relevant when a package is private.
This option determines whether require-* rules, if used, should enforce the presence of the corresponding property in package.json files that have "private": true.

By default, this is:

- false for require-name and require-version.
- true for every other require-* rule.

By specifying this setting as true or false, it will override the defaults and apply the setting for ALL rules.
In that case, either all require- rules will be applied to private packages or no require- rules will be applied to private packages.
Even then, you can override the setting again at the rule level, by using the rule's ignorePrivate option, which will take precedence over this global setting.

$3

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.\
📦 Set in the recommended-publishable configuration.\
🎨 Set in the stylistic configuration.\
🔧 Automatically fixable by the --fix CLI option.\
💡 Manually fixable by editor suggestions.\
❌ Deprecated.

| Name                         | Description | 💼 | 🔧 | 💡 | ❌ |
| :------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------ | :- | :- | :- |
| bin-name-casing | Enforce that names for bin properties are in kebab case. | 🎨 | | 💡 | |
| exports-subpaths-style | Enforce consistent format for the exports field (implicit or explicit subpaths). | 🎨 | 🔧 | | |
| no-empty-fields | Reports on unnecessary empty arrays and objects. | ✔️ ✅ 📦 | | 💡 | |
| no-redundant-files | Prevents adding unnecessary / redundant files. | ✔️ ✅ 📦 | | 💡 | |
| no-redundant-publishConfig | Warns when publishConfig.access is used in unscoped packages. | ✔️ ✅ 📦 | | 💡 | |
| order-properties | Package properties should be declared in standard order | 🎨 | 🔧 | | |
| repository-shorthand | Enforce either object or shorthand declaration for repository. | ✔️ ✅ 📦 | 🔧 | | |
| require-attribution | Ensures that proper attribution is included, requiring that either author or contributors is defined, and that if contributors is present, it should include at least one contributor. | 📦 | | 💡 | |
| require-author | Requires the author property to be present. | | | | |
| require-bugs | Requires the bugs property to be present. | | | | |
| require-bundleDependencies | Requires the bundleDependencies property to be present. | | | | |
| require-dependencies | Requires the dependencies property to be present. | | | | |
| require-description | Requires the description property to be present. | ✔️ ✅ 📦 | | | |
| require-devDependencies | Requires the devDependencies property to be present. | | | | |
| require-engines | Requires the engines property to be present. | | | | |
| require-exports | Requires the exports property to be present. | 📦 | | | |
| require-files | Requires the files property to be present. | 📦 | | | |
| require-homepage | Requires the homepage property to be present. | | | | |
| require-keywords | Requires the keywords property to be present. | | | | |
| require-license | Requires the license property to be present. | ✔️ ✅ 📦 | | | |
| require-name | Requires the name property to be present. | ✔️ ✅ 📦 | | | |
| require-optionalDependencies | Requires the optionalDependencies property to be present. | | | | |
| require-peerDependencies | Requires the peerDependencies property to be present. | | | | |
| require-repository | Requires the repository property to be present. | 📦 | | | |
| require-scripts | Requires the scripts property to be present. | | | | |
| require-sideEffects | Requires the sideEffects 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. | | | 💡 | |
| restrict-private-properties | Disallows unnecessary properties in private packages. | | 🔧 | 💡 | |
| scripts-name-casing | Enforce that names for scripts are in kebab case (optionally separated by colons). | 🎨 | | 💡 | |
| sort-collections | Selected collections must be in a consistent order (lexicographical for most; lifecycle-aware for scripts). | ✔️ ✅ 📦 | 🔧 | | |
| specify-peers-locally | Requires that all peer dependencies are also declared as dev dependencies | ✔️ ✅ 📦 | | 💡 | |
| unique-dependencies | Checks a dependency isn't specified more than once (i.e. in dependencies and devDependencies) | ✔️ ✅ 📦 | | 💡 | |
| valid-author | Enforce that the author property is valid. | ✔️ ✅ 📦 | | | |
| valid-bin | Enforce that the bin property is valid. | ✔️ ✅ 📦 | | | |
| valid-bundleDependencies | Enforce that the bundleDependencies (also: bundledDependencies) property is valid. | ✔️ ✅ 📦 | | | |
| valid-config | Enforce that the config property is valid. | ✔️ ✅ 📦 | | | |
| valid-contributors | Enforce that the contributors property is valid. | ✔️ ✅ 📦 | | | |
| valid-cpu | Enforce that the cpu property is valid. | ✔️ ✅ 📦 | | | |
| valid-dependencies | Enforce that the dependencies property is valid. | ✔️ ✅ 📦 | | | |
| valid-description | Enforce that the description property is valid. | ✔️ ✅ 📦 | | | |
| valid-devDependencies | Enforce that the devDependencies property is valid. | ✔️ ✅ 📦 | | | |
| valid-directories | Enforce that the directories property is valid. | ✔️ ✅ 📦 | | | |
| valid-engines | Enforce that the engines property is valid. | ✔️ ✅ 📦 | | | |
| valid-exports | Enforce that the exports property is valid. | ✔️ ✅ 📦 | | | |
| valid-files | Enforce that the files property is valid. | ✔️ ✅ 📦 | | | |
| valid-homepage | Enforce that the homepage property is valid. | ✔️ ✅ 📦 | | | |
| valid-keywords | Enforce that the keywords property is valid. | ✔️ ✅ 📦 | | | |
| valid-license | Enforce that the license property is valid. | ✔️ ✅ 📦 | | | |
| valid-main | Enforce that the main property is valid. | ✔️ ✅ 📦 | | | |
| valid-man | Enforce that the man property is valid. | ✔️ ✅ 📦 | | | |
| valid-module | Enforce that the module property is valid. | ✔️ ✅ 📦 | | | |
| valid-name | Enforce that package names are valid npm package names | ✔️ ✅ 📦 | | | |
| valid-optionalDependencies | Enforce that the optionalDependencies property is valid. | ✔️ ✅ 📦 | | | |
| valid-os | Enforce that the os property is valid. | ✔️ ✅ 📦 | | | |
| valid-package-definition | Enforce that package.json has all properties required by the npm spec | | | | ❌ |
| valid-peerDependencies | Enforce that the peerDependencies property is valid. | ✔️ ✅ 📦 | | | |
| valid-private | Enforce that the private property is valid. | ✔️ ✅ 📦 | | | |
| valid-publishConfig | Enforce that the publishConfig property is valid. | ✔️ ✅ 📦 | | | |
| valid-repository | Enforce that the repository property is valid. | ✔️ ✅ 📦 | | | |
| 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-sideEffects | Enforce that the sideEffects property is valid. | ✔️ ✅ 📦 | | | |
| valid-type | Enforce that the type property is valid. | ✔️ ✅ 📦 | | | |
| valid-version | Enforce that package versions are valid semver specifiers | ✔️ ✅ 📦 | | | |
| valid-workspaces | Enforce that the workspaces property is valid. | ✔️ ✅ 📦 | | | |

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.

$3

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.

$3

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 🐛 💻	AlexTheMan 🤔	Andreas Lindberg 🐛	Andrew Kazakov 🐛 💻 🤔 🔧	Anton Khitrenovich 🤔	Azat S. 🤔 💻	Brad Jorsch 🤔 🐛 💻
Christopher Buss 🐛 🤔 💻	Curtis Jewell 🤔	David LJ 📖	Eli 🤔 🐛	Flo Edelmann 📖	Heggria 🤔	Hiroki Osame 🤔 💻
James 💻 🤔 🐛 📖	James Zetlen 💻 🐛 📖 🚇 🚧 🔧	Jesús Leganés-Combarro 💻	Josh Goldberg ✨ 🔧 🐛 💻 🚇 📖 🚧 🤔 🖋 📆	Kendall Gassner 💻 🚧	Kristjan ESPERANTO 🤔 🐛 💻	Marco Pasqualetti 💻 🔧 🚧
Mathias Schreck 🤔	Michael "Mike" Ferris 💻	Morrison Cole 🐛	Nick Schonning 💻	Olivier Zalmanski 🚧 📖	Patrik Csak 🐛	Pavel 🤔 🔧 📖 💻 🐛
Sasial 💻	Stephen 💻	Stephen Zhou 🐛 💻 🤔 📖	Yosuke Ota 🐛 💻	b3rnhard 🐛	chouchouji 💻	michael faith 🚇 💻 🚧 🤔 🐛 🔧 📖
roottool 💻	sunnytsang1998 🐛

Appreciation

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.