Manifest (package.json) | Yarn

Manifest files (also called package.json because of their name) contain everything needed to describe the settings unique to one particular package. Project will contain multiple such manifests if they use the workspace feature, as each workspace is described through its own manifest. Note that defaults for these fields can be set via the initFields settings.
Name of the package.
Used to identify it across the application, especially amongst multiple workspaces. The first part of the name (here @scope/) is optional and is used as a namespace).
Version of the package.
Usually doesn't have any impact on your project, except when it is a workspace - then its version must match the specified ranges for the workspace to be selected as resolution candidate.
Define the package manager that should be used when working on this project.
This field is used by Corepack and similar tools to detect the Yarn version in use in a project - in a sense, it has the same purpose as your lockfile, but only for Yarn itself.
Yarn will automatically set this value when running yarn set version.
Define how should be interpreted .js files.
A Node.js v13.x option. Possible values are commonjs (the default) and module. Yarn 3+ will generate a .pnp.cjs file when using PnP regardless of this option.
Define whether the package is meant to be published.
If true, the package is considered private and Yarn will refuse to publish it regardless of the circumstances.
SPDX identifier defining the license under which the package is distributed.
Set of platforms on which this package works.
The value of process.platform() will be compared at install-time against this set. Should no matches be found, any postinstall script the package define will be skipped. If the package was exclusively depended upon via optionalDependencies entries, the package won't be installed at all.
Set of CPU architectures on which this package works.
The value of process.arch() will be compared at install-time against this set. Should no matches be found, any postinstall script the package define will be skipped. If the package was exclusively depended upon via optionalDependencies entries, the package won't be installed at all.
Set of C standard libraries on which this package depends.
The host standard library will be compared at install-time against this set. Should no matches be found, any postinstall script the package define will be skipped. If the package was exclusively depended upon via optionalDependencies entries, the package won't be installed at all.
Path of the file that should be resolved when requiring the package via a bare identifier.
This field can be modified at publish-time through the use of the publishConfig.main field.
Path of the file that should be resolved when requiring the package via a bare identifier in an ES6-compatible bundler environment.
This field should be considered deprecated, with exports being its official replacement.
Arbitrary value selecting the linker to use when installing the dependency.
This is an internal package setting that shouldn't be touched unless you really know what you're doing.
Set of files to expose via yarn run bin-name and the shell environment.
If set to a string, the binary value will be the package name (not including its scope part).
Set of scripts to expose via yarn run script-name, or as lifecycle hooks.
Scripts in Yarn are executed by a POSIX-like shell which implements most features you would want to use in one-liner scripts. For example you can assign environment variables using the POSIX syntax, and Yarn will make it work across both Linux, OSX, and Windows.
Set of dependencies that must be made available to the current package in order for it to work properly.
Consult the protocol documentation for more information.
Set of dependencies that Yarn should only try to install if the os/cpu/libc fields match those of the host platform.
Unlike regular dependencies, those listed in optionalDependencies are allowed to have a failing postinstall step - in fact, they won't even be installed at all if the os/cpu/libc filters don't cover the host platform.
Note that optionalDependencies only cares about whether the package should install/build or not - it should still be resolvable, as otherwise it's impossible to tell whether a failure to retrieve the package metadata is intentional or not.
Set of dependencies that must be made available to the current package in order for it to work properly as a workspace.
Unlike regular dependencies, those listed in devDependencies will only be required when the package is installed as part of a workspace project - usually by cloning the project repository then running yarn install inside it.
Set of dependencies that the package must inherit from its ancestor in the dependency tree.
The semantic of peer dependencies guarantee that when the package require the dependency, it will be returned the exact same object instance as the one that would be returned to the package's ancestor. This mechanism makes peer dependencies the best way to share singleton states across multiple packages.
As an extension, Yarn supports "peer dependencies with default": dependencies listed in both the dependencies and a peerDependencies fields will try to solve the peer dependency first, but will fallback to the regular dependency if it can't be satisfied otherwise.
Array of folder glob patterns referencing the workspaces of the project.