https://github.com/JoshuaKGoldberg/eslint-plugin-package-json
Rules for consistent, readable, and valid package.json files. 🗂️
https://github.com/JoshuaKGoldberg/eslint-plugin-package-json
eslint eslint-plugin json
Last synced: 9 months ago
JSON representation
Rules for consistent, readable, and valid package.json files. 🗂️
- Host: GitHub
- URL: https://github.com/JoshuaKGoldberg/eslint-plugin-package-json
- Owner: JoshuaKGoldberg
- License: mit
- Created: 2018-09-28T09:09:55.000Z (over 7 years ago)
- Default Branch: main
- Last Pushed: 2025-09-24T20:59:49.000Z (9 months ago)
- Last Synced: 2025-09-24T22:35:10.582Z (9 months ago)
- Topics: eslint, eslint-plugin, json
- Language: TypeScript
- Size: 3.94 MB
- Stars: 192
- Watchers: 5
- Forks: 32
- Open Issues: 48
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- Contributing: .github/CONTRIBUTING.md
- License: LICENSE.md
- Code of conduct: .github/CODE_OF_CONDUCT.md
- Security: .github/SECURITY.md
Awesome Lists containing this project
- awesome-eslint - eslint-plugin-package-json - Rules for consistent, readable, and valid package.json files. (Plugins / Languages and Environments)
- fucking-awesome-eslint - eslint-plugin-package-json - Rules for consistent, readable, and valid package.json files. (Plugins / Languages and Environments)
README
eslint-plugin-package-json
Rules for consistent, readable, and valid package.json files.
🗂️
## Installation
This package requires [ESLint](http://eslint.org) >=8:
```shell
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`](https://github.com/ota-meshi/jsonc-eslint-parser).
In your ESLint configuration file:
```ts
import packageJson from "eslint-plugin-package-json";
export default [
// your other ESLint configurations
packageJson.configs.recommended,
];
```
If you want to override the recommended rules:
```ts
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](https://eslint.org/docs/latest/use/configure/configuration-files-new) 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`](https://github.com/ota-meshi/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](https://eslint.org/docs/latest/use/configure/rules) 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",
},
},
],
};
```
### Settings
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";
export default {
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`](docs/rules/require-name.md) and [`require-version`](docs/rules/require-version.md).
- `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.
### Usage Alongside Prettier
**[`prettier-plugin-packagejson`](https://github.com/matzkoh/prettier-plugin-packagejson)** is a [Prettier plugin](https://prettier.io/docs/en/plugins) that enforces the same `package.json` keys ordering as the [`order-properties`](docs/rules/order-properties.md) and [sort-collections](docs/rules/sort-collections.md) 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](https://eslint.org/docs/user-guide/command-line-interface#--fix).\
💡 Manually fixable by [editor suggestions](https://eslint.org/docs/latest/use/core-concepts#rule-suggestions).\
❌ Deprecated.
| Name | Description | 💼 | 🔧 | 💡 | ❌ |
| :------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------- | :--- | :- | :- | :- |
| [no-empty-fields](docs/rules/no-empty-fields.md) | Reports on unnecessary empty arrays and objects. | ✔️ ✅ | | 💡 | |
| [no-redundant-files](docs/rules/no-redundant-files.md) | Prevents adding unnecessary / redundant files. | ✔️ ✅ | | 💡 | |
| [order-properties](docs/rules/order-properties.md) | Package properties must be declared in standard order | ✔️ ✅ | 🔧 | | |
| [repository-shorthand](docs/rules/repository-shorthand.md) | Enforce either object or shorthand declaration for repository. | ✔️ ✅ | 🔧 | | |
| [require-author](docs/rules/require-author.md) | Requires the `author` property to be present. | | | | |
| [require-bugs](docs/rules/require-bugs.md) | Requires the `bugs` property to be present. | | | | |
| [require-bundleDependencies](docs/rules/require-bundleDependencies.md) | Requires the `bundleDependencies` property to be present. | | | | |
| [require-dependencies](docs/rules/require-dependencies.md) | Requires the `dependencies` property to be present. | | | | |
| [require-description](docs/rules/require-description.md) | Requires the `description` property to be present. | ✔️ ✅ | | | |
| [require-devDependencies](docs/rules/require-devDependencies.md) | Requires the `devDependencies` property to be present. | | | | |
| [require-engines](docs/rules/require-engines.md) | Requires the `engines` property to be present. | | | | |
| [require-files](docs/rules/require-files.md) | Requires the `files` property to be present. | | | | |
| [require-keywords](docs/rules/require-keywords.md) | Requires the `keywords` property to be present. | | | | |
| [require-name](docs/rules/require-name.md) | Requires the `name` property to be present. | ✔️ ✅ | | | |
| [require-optionalDependencies](docs/rules/require-optionalDependencies.md) | Requires the `optionalDependencies` property to be present. | | | | |
| [require-peerDependencies](docs/rules/require-peerDependencies.md) | Requires the `peerDependencies` property to be present. | | | | |
| [require-type](docs/rules/require-type.md) | Requires the `type` property to be present. | ✔️ ✅ | | | |
| [require-types](docs/rules/require-types.md) | Requires the `types` property to be present. | | | | |
| [require-version](docs/rules/require-version.md) | Requires the `version` property to be present. | ✔️ ✅ | | | |
| [restrict-dependency-ranges](docs/rules/restrict-dependency-ranges.md) | Restricts the range of dependencies to allow or disallow specific types of ranges. | | | 💡 | |
| [sort-collections](docs/rules/sort-collections.md) | Selected collections must be in a consistent order (lexicographical for most; lifecycle-aware for scripts). | ✔️ ✅ | 🔧 | | |
| [unique-dependencies](docs/rules/unique-dependencies.md) | Checks a dependency isn't specified more than once (i.e. in `dependencies` and `devDependencies`) | ✔️ ✅ | | 💡 | |
| [valid-author](docs/rules/valid-author.md) | Enforce that the `author` property is valid. | ✔️ ✅ | | | |
| [valid-bin](docs/rules/valid-bin.md) | Enforce that the `bin` property is valid. | ✔️ ✅ | | 💡 | |
| [valid-bundleDependencies](docs/rules/valid-bundleDependencies.md) | Enforce that the `bundleDependencies` (also: `bundledDependencies`) property is valid. | ✔️ ✅ | | | |
| [valid-config](docs/rules/valid-config.md) | Enforce that the `config` property is valid. | ✔️ ✅ | | | |
| [valid-cpu](docs/rules/valid-cpu.md) | Enforce that the `cpu` property is valid. | ✔️ ✅ | | | |
| [valid-dependencies](docs/rules/valid-dependencies.md) | Enforce that the `dependencies` property is valid. | ✔️ ✅ | | | |
| [valid-description](docs/rules/valid-description.md) | Enforce that the `description` property is valid. | ✔️ ✅ | | | |
| [valid-devDependencies](docs/rules/valid-devDependencies.md) | Enforce that the `devDependencies` property is valid. | ✔️ ✅ | | | |
| [valid-directories](docs/rules/valid-directories.md) | Enforce that the `directories` property is valid. | ✔️ ✅ | | | |
| [valid-exports](docs/rules/valid-exports.md) | Enforce that the `exports` property is valid. | ✔️ ✅ | | | |
| [valid-license](docs/rules/valid-license.md) | Enforce that the `license` property is valid. | ✔️ ✅ | | | |
| [valid-local-dependency](docs/rules/valid-local-dependency.md) | Checks existence of local dependencies in the package.json | | | | ❌ |
| [valid-name](docs/rules/valid-name.md) | Enforce that package names are valid npm package names | ✔️ ✅ | | | |
| [valid-optionalDependencies](docs/rules/valid-optionalDependencies.md) | Enforce that the `optionalDependencies` property is valid. | ✔️ ✅ | | | |
| [valid-package-definition](docs/rules/valid-package-definition.md) | Enforce that package.json has all properties required by the npm spec | ✔️ ✅ | | | |
| [valid-peerDependencies](docs/rules/valid-peerDependencies.md) | Enforce that the `peerDependencies` property is valid. | ✔️ ✅ | | | |
| [valid-repository-directory](docs/rules/valid-repository-directory.md) | Enforce that if repository directory is specified, it matches the path to the package.json file | ✔️ ✅ | | 💡 | |
| [valid-scripts](docs/rules/valid-scripts.md) | Enforce that the `scripts` property is valid. | ✔️ ✅ | | | |
| [valid-type](docs/rules/valid-type.md) | Enforce that the `type` property is valid. | ✔️ ✅ | | | |
| [valid-version](docs/rules/valid-version.md) | 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`](./.github/CONTRIBUTING.md), then [`.github/DEVELOPMENT.md`](./.github/DEVELOPMENT.md).
Thanks! 🗂
## Contributors
Alan
🐛 💻
Andreas Lindberg
🐛
Andrew Kazakov
🐛 💻 🤔
Anton Khitrenovich
🤔
Azat S.
🤔 💻
Brad Jorsch
🤔 🐛 💻
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
🐛
## Appreciation
Many thanks to [@zetlen](https://github.com/zetlen) for creating the initial version and core infrastructure of this package! 💖
> 💝 This package was templated with [`create-typescript-app`](https://github.com/JoshuaKGoldberg/create-typescript-app) using the [Bingo engine](https://create.bingo).