Advanced interpretation of package.json configuration

foreword

package.json is a json file that every front-end project will have, located in the root directory of the project. Many scaffolds will automatically initialize package.json for us when creating a project. There are many configurations in package.json that are closely related to the project. Understanding them is helpful for the development of the project. The previous article has completed the explanation of the basic configuration of package.json, and then we will start learning the rest.

Today we mainly introduce some commonly used configurations, which are divided into seven categories, namely:

  • Dependency configuration
  • publish configuration
  • System Configuration
  • third party configuration

1. Dependency configuration

The project development process will depend on other packages, and the information of these dependencies needs to be configured in package.json.

dependencies

Running dependencies, that is, the dependencies that need to be used in the production environment of the project. Such as vue, vuex and component libraries.
When using npm install xxx or npm install xxx --save, it will be automatically inserted into this field.

  "dependencies": {
    
    
    "element-plus": "^2.2.28",
    "pinia": "^2.0.28",
    "sass": "^1.57.1",
    "vite": "^4.0.3",
    "vue": "^3.2.45",
    "vue-router": "^4.1.6"
  },

devDependencies

Development dependencies, dependencies that are needed in the project development environment but not needed at runtime, are used to assist development, usually including project engineering tools such as vite, eslint, etc.
When using npm install xxx -D or npm install xxx --save-dev, it will be automatically inserted into this field.

  "devDependencies": {
    
    
    "cz-git": "^1.4.1",
    "eslint": "^8.30.0",
    "eslint-config-airbnb-base": "^15.0.0",
    "eslint-config-prettier": "^8.5.0",
    "eslint-define-config": "^1.12.0",
    "eslint-plugin-import": "^2.26.0",
    "eslint-plugin-prettier": "^4.2.1",
    "eslint-plugin-vue": "^9.8.0",
    "husky": "^8.0.0",
    "less": "^4.1.3",
    "lint-staged": "^13.1.0",
    "postcss-html": "^1.5.0",
    "postcss-less": "^6.0.0",
    "prettier": "^2.8.1",
    "stylelint": "^14.16.0",
    "stylelint-config-html": "^1.1.0",
  }

peerDependencies

Companion dependencies are special dependencies that will not be installed automatically, and are usually used to indicate a dependency and compatibility relationship with another package to warn users.

optionalDependencies

Optional dependency, which means that the dependency is optional, it will not block the use of the main function, and it does not matter if the installation or import fails. If the installation of such dependencies fails, the entire installation process of npm is also successful.
When using npm install xxx -O or npm install xxx --save-optional, dependencies will be automatically inserted into this field.

bundleDependencies

Packaging dependencies. Its value is an array. When publishing the package, the dependencies in bundleDependencies will be packaged together.
In the tgz compressed package generated by executing npm pack, node_modules will appear and contain react and react-dom.

It should be noted that the values ​​in this field array must be dependencies declared in both dependencies and devDependencies. Ordinary dependencies are usually installed from npm registry, but when you want to use a package that is not in npm registry, or a third-party package that has been modified, packaged dependencies are better than ordinary dependencies.

2. Release configuration

Mainly some configuration related to project publishing

private

If it is a private project and you don't want to publish it on the public npm warehouse, you can set private to true.

"private": true

publishConfig

publishConfig is the configuration used when the npm package is published.
For example, when installing dependencies, you specify registry as the taobao image source, but you want to publish on the public network when publishing, you can specify publishConfig.registry.

"publishConfig": {
    
    
  "registry": "https://registry.npmjs.org/"
}

3. System configuration

System configuration related to the project, such as node version or operating system compatibility. But it is worth noting that these requirements will only serve as a warning, even if the user's environment does not meet the requirements, it will not affect the installation of dependent packages.

engines

Some projects have specific version number requirements for node or package manager due to compatibility issues. For example, the version number of node is required to be greater than or equal to 12 and less than 16, and the version number of pnpm must be greater than 7.

"engines": {
    
    
  "node": ">=12 <16",
  "pnpm": ">7"
}

os

Projects that can run normally on linux may have exceptions on windows. Use the os field to specify the compatibility requirements of the project for the operating system.

"os": ["darwin", "linux"]

cpu

Specifies that the project can only run on a specific CPU architecture.

"cpu": ["x64", "ia32"]

4. Third-party configuration

Some third-party libraries or applications rely on these fields when performing some internal processing, and the corresponding third-party libraries need to be installed when using them.

types or typings

Specify the entry file for TypeScript's type definition

"types": "./index.ts",

browserslist

Sets the browser compatibility of the project. Tools like babel and autoprefixer use this configuration to transpile your code. Of course you can also use the .browserslistrc single file configuration.

"browserslist": [
  "> 1%",
  "last 2 versions"
]

sideEffects

Display setting some modules have side effects, used for webpack's tree-shaking optimization.
For example, import the css file of the Ant Design component library into the project as a whole.

import 'antd/dist/antd.css'; 

If sideEffects is not set in Ant Design's package.json, then webapck will think that this code is only introduced but not used when building and packaging. It can be removed by tree-shaking, which will eventually cause the product to lack styles.

lint-staged

lint-staged is a tool for operating files in the temporary storage area of ​​git. For example, it can perform lint verification, type checking, image optimization and other operations before code submission.

"lint-staged": {
    
    
  "src/**/*.{js,jsx,ts,tsx}": [
    "eslint --fix",
    "git add -A"
  ]
}

lint-staged is usually used together with git-hooks tools like husky. git-hooks is used to define a hook, these hook methods will be triggered in the git workflow such as pre-commit, commit-msg, you can put lint-staged into these hook methods.

V. Conclusion

Today we briefly learned about the common configuration of package.json. With this knowledge, we can better understand the project. But the content in package.json is much more than that, we need to study further.

Guess you like

Origin blog.csdn.net/qq_44880095/article/details/128565344