ESLint Plugin: Package JSON

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

Getting Started

See Getting Started for details.

Supported Rules

Configurations enabled in.
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.

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-local-dependencies	Requires that dependencies do not use local file paths, which will likely result in errors when installing from a registry.
no-redundant-files	Prevents adding unnecessary / redundant files.
no-redundant-publishConfig	Warns when publishConfig.access is used in unscoped packages.
order-properties	Enforces that package properties are declared in a consistent 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.
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.
restrict-top-level-properties	Disallows specified top-level properties in package.json.
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-peerDependenciesMeta-relationship	Enforces that any dependencies declared in peerDependenciesMeta are also defined in the package's peerDependencies.
valid-repository-directory	Enforce that if repository directory is specified, it matches the path to the package.json file

Require Properties

This group of rules allows you to require that the associated top-level property must be present in the package.json.

Name	Description
require-author	Requires the author property to be present.
require-bin	Requires the bin property to be present.
require-browser	Requires the browser property to be present.
require-bugs	Requires the bugs property to be present.
require-bundleDependencies	Requires the bundleDependencies property to be present.
require-config	Requires the config property to be present.
require-contributors	Requires the contributors property to be present.
require-cpu	Requires the cpu 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-devEngines	Requires the devEngines property to be present.
require-directories	Requires the directories 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-funding	Requires the funding property to be present.
require-gypfile	Requires the gypfile property to be present.
require-homepage	Requires the homepage property to be present.
require-keywords	Requires the keywords property to be present.
require-libc	Requires the libc property to be present.
require-license	Requires the license property to be present.
require-main	Requires the main property to be present.
require-man	Requires the man property to be present.
require-module	Requires the module property to be present.
require-name	Requires the name property to be present.
require-optionalDependencies	Requires the optionalDependencies property to be present.
require-os	Requires the os property to be present.
require-packageManager	Requires the packageManager property to be present.
require-peerDependencies	Requires the peerDependencies property to be present.
require-peerDependenciesMeta	Requires the peerDependenciesMeta property to be present.
require-private	Requires the private property to be present.
require-publishConfig	Requires the publishConfig 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.

Valid Properties

This group of rules allows you to enforce that the value of the associated top-level property is valid. All of these rules are include in the recommended config.

Name	Description
valid-author	Enforce that the author property is valid.
valid-bin	Enforce that the bin property is valid.
valid-browser	Enforce that the browser property is valid.
valid-bugs	Enforce that the bugs 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-devEngines	Enforce that the devEngines 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-funding	Enforce that the funding property is valid.
valid-gypfile	Enforce that the gypfile property is valid.
valid-homepage	Enforce that the homepage property is valid.
valid-keywords	Enforce that the keywords property is valid.
valid-libc	Enforce that the libc 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 the name property is valid.
valid-optionalDependencies	Enforce that the optionalDependencies property is valid.
valid-os	Enforce that the os property is valid.
valid-packageManager	Enforce that the packageManager property is valid.
valid-peerDependencies	Enforce that the peerDependencies property is valid.
valid-peerDependenciesMeta	Enforce that the peerDependenciesMeta 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-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 the version property is valid.
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.

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	AlexTheMan	Andreas Lindberg	Andrew Kazakov	Anton Khitrenovich	Azat S.	Brad Jorsch
Christopher Buss	Clément Valot	Curtis Jewell	David LJ	Eli	Flo Edelmann	Heggria
Hiroki Osame	Ivan Uhalin	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	Sergey Belozyorcev	Shayan Zamani	Sigmabro	Stephen
Stephen Zhou	Wes Todd	Yosuke Ota	b3rnhard	chouchouji	michael faith	roottool
sunnytsang1998

License

See the LICENSE file for license rights and limitations (MIT).