package.json
The manifest file of a package. It contains all the package's metadata, including dependencies, title, author, et cetera. This is a standard preserved across all major Node.js package managers, including pnpm.
In addition to the traditionalpackage.json format, pnpm also supportspackage.json5 (viajson5) andpackage.yaml (viajs-yaml).
engines
You can specify the version of Node and pnpm that your software works on:
{
"engines":{
"node":">=10",
"pnpm":">=3"
}
}
During local development, pnpm will always fail with an error message if its version does not match the one specified in theengines field.
Unless the user has set theengineStrict config flag (seesettings), this field is advisory only and will only produce warnings when your package is installed as a dependency.
dependenciesMeta
Additional meta information used for dependencies declared insidedependencies,optionalDependencies, anddevDependencies.
dependenciesMeta.*.injected
If this is set totrue for a dependency that is a local workspace package, that package will be installed by creating a hard linked copy in the virtual store (node_modules/.pnpm).
If this is set tofalse or not set, then the dependency will instead be installed by creating anode_modules symlink that points to the package's source directory in the workspace. This is the default, as it is faster and ensures that any modifications to the dependency will be immediately visible to its consumers.
For example, suppose the followingpackage.json is a local workspace package:
{
"name":"card",
"dependencies":{
"button":"workspace:1.0.0"
}
}
Thebutton dependency will normally be installed by creating a symlink in thenode_modules directory ofcard, pointing to the development directory forbutton.
But what ifbutton specifiesreact in itspeerDependencies? If all projects in the monorepo use the same version ofreact, then there is no problem. But what ifbutton is required bycard that usesreact@16 andform that usesreact@17? Normally you'd have to choose a single version ofreact and specify it usingdevDependencies ofbutton. Symlinking does not provide a way for thereact peer dependency to be satisfied differently by different consumers such ascard andform.
Theinjected field solves this problem by installing a hard linked copies ofbutton in the virtual store. To accomplish this, thepackage.json ofcard could be configured as follows:
{
"name":"card",
"dependencies":{
"button":"workspace:1.0.0",
"react":"16"
},
"dependenciesMeta":{
"button":{
"injected":true
}
}
}
Whereas thepackage.json ofform could be configured as follows:
{
"name":"form",
"dependencies":{
"button":"workspace:1.0.0",
"react":"17"
},
"dependenciesMeta":{
"button":{
"injected":true
}
}
}
With these changes, we say thatbutton is an "injected dependency" ofcard andform. Whenbutton importsreact, it will resolve toreact@16 in the context ofcard, but resolve toreact@17 in the context ofform.
Because injected dependencies produce copies of their workspace source directory, these copies must be updated somehow whenever the code is modified; otherwise, the new state will not be reflected for consumers. When building multiple projects with a command such aspnpm --recursive run build, this update must occur after each injected package is rebuilt but before its consumers are rebuilt. For simple use cases, it can be accomplished by invokingpnpm install again, perhaps using apackage.json lifecycle script such as"prepare": "pnpm run build" to rebuild that one project. Third party tools such aspnpm-sync andpnpm-sync-dependencies-meta-injected provide a more robust and efficient solution for updating injected dependencies, as well as watch mode support.
peerDependenciesMeta
This field lists some extra information related to the dependencies listed in thepeerDependencies field.
peerDependenciesMeta.*.optional
If this is set to true, the selected peer dependency will be marked as optional by the package manager. Therefore, the consumer omitting it will no longer be reported as an error.
Misalnya:
{
"peerDependencies":{
"foo":"1"
},
"peerDependenciesMeta":{
"foo":{
"optional":true
},
"bar":{
"optional":true
}
}
}
Note that even thoughbar was not specified inpeerDependencies, it is marked as optional. pnpm will therefore assume that any version of bar is fine. However,foo is optional, but only to the required version specification.
publishConfig
It is possible to override some fields in the manifest before the package is packed. The following fields may be overridden:
To override a field, add the publish version of the field topublishConfig.
For instance, the followingpackage.json:
{
"name":"foo",
"version":"1.0.0",
"main":"src/index.ts",
"publishConfig":{
"main":"lib/index.js",
"typings":"lib/index.d.ts"
}
}
Will be published as:
{
"name":"foo",
"version":"1.0.0",
"main":"lib/index.js",
"typings":"lib/index.d.ts"
}
publishConfig.executableFiles
By default, for portability reasons, no files except those listed in the bin field will be marked as executable in the resulting package archive. TheexecutableFiles field lets you declare additional files that must have the executable flag (+x) set even if they aren't directly accessible through the bin field.
{
"publishConfig":{
"executableFiles":[
"./dist/shim.js"
]
}
}
publishConfig.directory
You also can use the fieldpublishConfig.directory to customize the published subdirectory relative to the currentpackage.json.
It is expected to have a modified version of the current package in the specified directory (usually using third party build tools).
In this example the
"dist"folder must contain apackage.json
{
"name":"foo",
"version":"1.0.0",
"publishConfig":{
"directory":"dist"
}
}
publishConfig.linkDirectory
- Default:true
- Type:Boolean
When set totrue, the project will be symlinked from thepublishConfig.directory location during local development.
Misalnya:
{
"name":"foo",
"version":"1.0.0",
"publishConfig":{
"directory":"dist",
"linkDirectory":true
}
}