Description of the package.json file

Document copy yarnpkg official document, not exactly copy, add some content and some description as note store. You can also refer to NPM Documentation, STD-Pkg, clean-publish, package-JSON-validator, Cosmiconfig, RC.

Welcome to Star: github.com/jaywcjlove/…

Important fields

The two most important fields in your package.json are name and Version, without which your package will not install. The name and Version fields are used together to create a unique ID.

`name`

{
  "name": "my-awesome-package"
}
Copy the code

This is the name of your package. It is used in urls, as argument command lines, and directory names in node_modules.

Yarn add [package name]# orNPM installCopy the code

Node_modules / [package name]Copy the code

https://registry.npmjs.org/ / package / - / [package name] - [version] TGZCopy the code

The rules

Must be less than or equal to 214 characters (inclusive@scope/For scope package).
No point (.) or underline (_) at the beginning.
The name must not contain uppercase letters.
You must use only URL-safe characters.

Tips

Don’t use andNode.jsThe core module has the same name.
Don’t include it in the namejsornodeWords.
Be short and concise, so that the name gives a general idea of what the package will do, and remember that it will also be used inrequire()In the call.
Ensure that the name is unique in NPM Registry.

`version`

The current version of the package strictly follows the Semantic Versioning 2.0.0 Semantic version specification.

{
  "version": "1.0.0"
}
Copy the code

Information field

`description`

Description is a string that helps the consumer understand the functionality of the package, and the package manager uses this string as a search term.

{
  "description": "Summary brief description of my bag."
}
Copy the code

`keywords`

Keywords are an array of strings that are useful when searching for packages in the package manager.

{
  "keywords": ["short"."relevant"."keywords"."for"."searching"]}Copy the code

`license`

All packages should be licensed so that users know under what authorization they are using the package and what additional restrictions the package has.

{
  "license": "MIT"."license": "(MIT or GPL - 3.0)"."license": "SEE LICENSE IN LICENSE_FILENAME.txt"."license": "UNLICENSED"
}
Copy the code

Use of the open Source (OSI-approved) license is encouraged unless you have a specific reason not to use it. If the package you’re developing is part of your job, it’s best to discuss it with the company before making a decision.

The license field must be one of the following:

If you use a standard license, you need a valid SPDX license identifier.
If you use multiple standard licenses, you need a valid SPDX License Expression 2.0 syntax expression.
If you use a non-standard license, oneSEE LICENSE IN < file name >The string points to a < filename > in the top-level directory of your package.
If you do not wish to authorize others to use your private or unpublished package under any terms, oneUNLICENSEDA string.

Link class field

Various link fields to project documentation, issues reporting, and code hosting sites.

`homepage`

Is the project or document home page of the package.

{
  "homepage": "https://your-package.org"
}
Copy the code

`bugs`

The URL of the problem feedback system, or a link like an email address. This is a way for users to report problems to you.

{
  "bugs": "https://github.com/user/repo/issues"
}
Copy the code

`repository`

Is where the code is hosted.

{
  "repository": { "type": "git"."url": "https://github.com/user/repo.git" },
  "repository": "github:user/repo"."repository": "gitlab:user/repo"."repository": "bitbucket:user/repo"."repository": "gist:a1b2c3d4e5f"
}
Copy the code

The repository is the location where the actual code for your package lives.

Project maintenance class field

Project maintainer.

`author`

Author information, one person.

{
  "author": { "name": "Your Name"."email": "[email protected]"."url": "http://your-website.com" },
  "author": "Your Name <[email protected]> (http://your-website.com)"
}
Copy the code

`contributors`

Contributor information, possibly many people.

{
  "contributors": [{"name": "Your Friend"."email": "[email protected]"."url": "http://friends-website.com" }
    { "name": "Other Friend"."email": "[email protected]"."url": "http://other-website.com"}]."contributors": [
    "Your Friend <[email protected]> (http://friends-website.com)"."Other Friend <[email protected]> (http://other-website.com)"]}Copy the code

File Class Information

Specifies the files included in the project, as well as the entry files for the project.

`files`

{
  "files": [
    "filename.js"."directory/"."glob/*.{js,json}"]}Copy the code

The project contains files that can be individual files, entire folders, or wildcard matched files.

`main`

Entry file for the project.

{
  "main": "filename.js"
}
Copy the code

`bin`

An executable that is installed with the project.

{
  "bin": "bin.js"."bin": {
    "Command name": "Bin/command path/command name.js"."other-command": "bin/other-command"}}Copy the code

`man`

Entry file for the project.

{
  "man": "./man/doc.1"."man": ["./man/doc.1"."./man/doc.2"]}Copy the code

`directories`

{
  "directories": {
    "lib": "path/to/lib/"."bin": "path/to/bin/"."man": "path/to/man/"."doc": "path/to/doc/"."example": "path/to/example/"}}Copy the code

When your package is installed, you can specify the exact location to put binaries, man Pages, documents, examples, and so on.

`types`

This is a field that only works in TypeScript. If your package has a main.js file, you also need to specify the main declaration file in package.json. Set the types attribute to point to bundled’s declaration file. Such as:

{
  "types": "./lib/main.d.ts",}Copy the code

If your main declaration file is named index.d.ts and is located in the root directory of the package (next to index.js), you do not need to mark the types attribute, which is recommended.

Bag packing field

`module`

Pkg.module will point to modules that have ES2015 module syntax, but only to syntactic functionality supported by the target environment. The full description is here.

Support: Rollup, Webpack

`browser`

Fields are provided by the module author as prompts for JavaScript packages or component tools to package the module for use by the client. The proposal is right here.

`esnext`

The full proposal is here. Brief description:

esnext: ES module using stage 4 functionality (or older) source code, not compiled.
main: points to a CommonJS module (or UMD module) whoseJavaScript 与 Node.jsCurrent can handle as modern.
Most of themoduleUse cases should passesnextTo deal with.
browserCan be achieved byesnextExtended version to handle

{
  "main": "main.js"."esnext": {
    "main": "main-esnext.js"."browser": "browser-specific-main-esnext.js"}}Copy the code

See also: Delivering untranspiled Source code via NPM

Task-class field

Packages can also contain executable scripts or other configuration information.

`scripts`

{
  "scripts": {
    "build-project": "node build-project.js"}}Copy the code

Scripting is a good way to define tasks related to automated development, such as using some simple build process or development tools. The scripts defined in the scripts field can be executed using the YARN run

There are some special script names. If the preinstall script is defined, it will be invoked before the package is installed. For compatibility reasons, install, postinstall, and prepublish scripts are invoked after the package is installed.

The default value of the start script is Node server.js.

Reference: NPM docs

specific`scripts`

NPM supports the default command fields of package.json files for the following scripts:

prepublish: runs before the package is packaged and distributed, and locally without any parametersnpmRun before installation. (See below)
prepare: Runs before packaging and publishing packages, locally without any parametersnpm installAnd when you install git dependencies (see below). This is thepreublishRun after, but inpreublishOnlyRun before.
prepublishOnly: runs before package preparation and packaging, only for NPM releases. (See below.)
prepack: in the packagingtarballBefore running (innpm pack.npm publishAnd when installing Git dependencies)
postpack: in the generatedtarballIt then runs and moves to its final destination.
publish.postpublish: Runs after the package is published.
preinstall: Runs before installing the software package.
install.postinstall: Install the package and run it.
preuninstall.uninstall: Runs before uninstalling the software package.
postuninstall: Runs after uninstalling the software package.
preversion: Runs before changing the package version.
version: Run after changing package version, but before committing.
postversion: Change the package version and run it, then commit.
pretest.test.posttestBy:npm testCommand run.
prestop.stop.poststopBy:npm stopCommand run.
prestart.start.poststartBy:npm startCommand run.
prerestart.restart.postrestartBy:npm restartCommand run. Note: If no restart script is provided,npm restartWill runstop 和startThe script.
preshrinkwrap.shrinkwrap.postshrinkwrapBy:npm shrinkwrapCommand run.

Reference: NPM docs.

`config`

{
  "config": {
    "port": "8080"}}Copy the code

Configure the options or parameters for your script.

Dependency description class field

Your package is likely to depend on other packages. You can specify those dependencies in your package.json file.

`dependencies`

These are the dependencies that both the development and distribution versions of your package will need.

{
  "dependencies": {
    "package-1": "^ 3.1.4." "."package-2": "file:./path/to/dir"}}Copy the code

You can specify an exact version, a minimum version (e.g. >=), or a range of versions (e.g. >=… <). Packages can also point to a local directory folder.

`devDependencies`

These are packages that are only needed during your package development, but will not be installed in production.

{
  "devDependencies": {
    "package-2": "^ 0.4.2"}}Copy the code

`peerDependencies`

Parallel dependencies allow you to indicate the compatibility of your package with other package versions.

{
  "peerDependencies": {
    "package-3": "^ 2.7.18"}}Copy the code

`optionalDependencies`

Optional dependencies can be used for your package, but are not required. If the optional package is not found, installation can continue.

{
  "optionalDependencies": {
    "package-5": "^ 1.6.1." "}}Copy the code

`bundledDependencies`

Package dependencies are an array of package names that will be packaged with your package when you publish it.

{
  "bundledDependencies": [
    "package-4"]}Copy the code

system

You can provide system-level information associated with your package, such as operating system compatibility.

`engines`

Specify the version that your package client must use. This checks process.versions as well as the current YARN version.

{
  "engines": {
    "node": "> = 4.4.7 < 7.0.0"."zlib": "^ 1.2.8"."yarn": "^ 0.14.0"}}Copy the code

This check follows the normal Semver rules, with one exception. It allows pre-released versions to match semvers that are not explicitly pre-released. For example, 1.4.0-RC.0 matches >=1.3.0, but it does not match a typical Semver check.

`os`

This option specifies the operating system compatibility of your package. It checks process.platform.

{
  "os": ["darwin"."linux"]."os": [! "" win32"]}Copy the code

`cpu`

Use this option to specify that your package will only run on certain CPU architectures, which checks process.arch.

{
  "cpu": ["x64"."ia32"]."cpu": [! "" arm".! "" mips"]}Copy the code

release

`private`

{
  "private": true
}
Copy the code

Set this to true if you do not want your packages to be published to the package manager (NPM or private package manager).

`publishConfig`

These configuration values will be used when your package is released. For example, you can tag bags.

{
  "publishConfig": {
    "registry": "https://registry.npm.taobao.org"}}Copy the code

This is a set of configuration values that will be used at publish time. This is especially handy if you want to set the tag, registry, or access rights to ensure that a given package is not marked as Latest, published to the global public Registry, or that the scoped module (@scoped) is private by default.

Any configuration value can be overridden, but only tag, Registry, and Access may be important for publishing, nPM-config.

Yarn

`flat`

If your package only allows one version of a given dependency and you want to enforce the same behavior as yarn install –flat on the command line, set this value to true.

{
  "flat": true
}
Copy the code

Note that if your package.json contains “flat”: true and other packages depend on your package (e.g., you are building a library, not an application), those other packages also need to add “flat” to their package.json: True, or install yarn install –flat on the command line.

`resolutions`

{
  "resolutions": {
    "transitive-package-1": "0.0.29"."transitive-package-2": "file:./local-forks/transitive-package-2"."dependencies-package-1/transitive-package-3": "^ 2.1.1"}}Copy the code

Allows you to override versions of specific nested dependencies. For the full specification, see Selective version Resolution RFC.

Note that the YARN install –flat command will automatically add the Resolutions field to the package.json file.

Description of the package.json file

Important fields

name

version

Information field

description

keywords

license

Link class field

homepage

bugs

repository

Project maintenance class field

author

contributors

File Class Information

files

main

bin

man

directories

types

Bag packing field

module

browser

esnext

Task-class field

scripts

specificscripts

config