The package.json file is the project configuration file. Common configurations include configuring project startup, packaging commands, and declaring dependent packages. The package.json file is a JSON object, and each member of the object is a setting of the current project.
{
"name": "monorepo_frame",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"install:all": "sh script/installAll.sh",
"doc:api": "sh script/api_doc.sh",
"build:ui": "pnpm --filter @web/ui run build ",
"test:ui": "pnpm --filter @web/ui test ",
"test:core": "pnpm --filter @web/core test ",
"dev:exproject": "pnpm --filter @@zqxx/exproject dev ",
"build:demo": "rimraf docs/demo && pnpm --filter @web/demo build ",
"dev:rest": "pnpm --filter @web/rest dev ",
"build:rest": "rimraf docs/rest && pnpm --filter @web/rest build ",
"build:all": "pnpm run build:demo",
"publish": " sh script/publish.sh",
"prettier": "prettier --write ."
},
"workspaces": [
"packages/*"
],
"keywords": [],
"author": "",
"license": "ISC",
"devDependencies": {
"@element-plus/icons": "^0.0.11",
"@element-plus/icons-vue": "^2.0.10",
"@types/lodash-es": "*",
"@types/node": "^17.0.45",
"@vitejs/plugin-vue": "^4.0.0",
"@vitejs/plugin-vue-jsx": "^3.0.0",
"@vue/compiler-sfc": "^3.2.45",
"element-plus": "2.3.3",
"eslint": "^8.27.0",
"minimist": "^1.2.7",
"mockjs": "^1.1.0",
"sass": "^1.56.1",
"typescript": "^4.9.3",
"unplugin-auto-import": "^0.12.0",
"unplugin-vue-components": "^0.22.11",
"vite": "^4.0.0",
"vite-plugin-dts": "^1.7.1",
"vite-plugin-mock": "2.9.6",
"vite-plugin-top-level-await": "^1.2.4",
"vue": "^3.2.45",
"vue-router": "^4.1.6",
"vue-tsc": "^0.32.1"
},
"dependencies": {
"@element-plus/icons-vue": "^2.0.10",
"@element-plus/utils": "^0.0.5",
"@kangc/v-md-editor": "^2.3.15",
"@vueuse/core": "^8.9.4",
"codemirror": "^5.65.9",
"crypto-js": "^4.1.1",
"echarts": "^5.4.0",
"highlight.js": "^11.7.0",
"ismobilejs": "^1.1.1",
"mockjs": "^1.1.0",
"normalize.css": "^8.0.1",
"nprogress": "^0.2.0",
"pinia": "^2.0.35",
"pinia-plugin-persistedstate": "^3.1.0",
"terser": "^5.16.3",
"vite-plugin-inspect": "^0.7.7",
"vue-i18n": "9.1.10",
"vuex": "^4.1.0"
}
}
When we clone a new project locally, we need to execute the npm install (yarn install) command to install the dependency files required by the project. When this command is executed, the required modules will be automatically downloaded based on the configuration information in the package.json file, which is to configure the running and development environment required for the project.
1. Required attributes
The two most important fields in package.json are name and version. They are both required. Without them, the npm install command cannot be executed normally. npm stipulates that package.json files are uniquely identified by name and version number.
1. name
name is easy to understand, it is the name of the project, it is a string. When naming the name field, you need to pay attention to the following points:
-
The name must be less than or equal to 214 characters long, cannot start with "." and "_", and cannot contain uppercase letters (this is because when the package is published on npm, it will get its own URL based on this attribute, so it cannot Contains non-url-safe characters (non-url-safe));
-
The name can be passed into require("") as a parameter to import the module, so it should be as short and semantic as possible;
-
The name cannot be the same as the name of other modules. You can use the npm view command to check whether the module name is repeated. If it is not repeated, a 404 message will be displayed:
-
-
If there is a corresponding package on the npm package, the detailed information of the package will be displayed:
-
-
In fact, many of the projects we usually develop are not published on npm, so whether the name is standard or not may not be that important, as it will not affect the normal operation of the project. If it needs to be published on npm, the name field must meet the requirements.
2. version
The version field represents the version number of the project package, which is a string. After each project change, the version number of the project must be changed synchronously when it is about to be released. The usage specifications of version numbers are as follows:
-
The naming of the version number follows the Semantic Version 2.0.0 specification, and the format is:"Major version number. Minor version number. Revision number", usually, changing the major version number means making major functional changes, changing the minor version number means adding new features, changing the revision number means fixing some bugs;
-
If a certain version has major changes and is unstable, and may not meet the expected compatibility requirements, it is necessary to release an advance version. If the advance version passes, it will be added to the end of the version number and connected by a "-" sign separated by dots. Identifier and version compilation information: internal version (alpha), public test version (beta) and candidate version (rc, release candidate).
2. Description information
There are five configuration fields in package.jaon related to the project package description information. Let’s take a look at the meaning of these fields respectively.
1. description
The description field is used to describe this project package. It is a string that allows other developers to discover our project package in npm search.
2. keywords
The keywords field is an array of strings representing the keywords of this project package. Like description, they are used to increase the exposure of the project package. The following is the description and keywords of the eslint package:
3. author
author, as the name implies, is the author, indicating the author of the project package. It has two forms, one is string format:
"author": "CUGGZ <[email protected]> (https://juejin.cn/user/3544481220801815)"The other is the object form:
"author": {
"name" : "CUGGZ",
"email" : "[email protected]",
"url" : "https://juejin.cn/user/3544481220801815"
}4. contributors
contributors represents the contributors of the project package. Different from author, this field is an array containing all contributors. It also has two ways of writing
"contributors": [
"CUGGZ0 <[email protected]> (https://juejin.cn/user/3544481220801815)",
"CUGGZ1 <[email protected]> (https://juejin.cn/user/3544481220801815)"
]"contributors": [
{
"name" : "CUGGZ0",
"email" : "[email protected]",
"url" : "https://juejin.cn/user/3544481220801815"
},
{
"name" : "CUGGZ1",
"email" : "[email protected]",
"url" : "https://juejin.cn/user/3544481220801815"
}
]5. homepage
Homepage is the homepage address of the project, which is a string.
6. repository
repository represents the code storage warehouse address, usually in two writing forms. The first is the string form
3. Dependency configuration
Normally, our projects will depend on one or more external dependency packages. Depending on the different uses of the dependency packages, they can be configured under the following five attributes: dependencies, devDependencies, peerDependencies, bundledDependencies, and optionalDependencies. Let’s take a look at the meaning of each attribute.
1. dependencies
Declared in the dependencies field are the dependency packages necessary for the project's production environment. When using npm or yarn to install an npm package, the npm package will be automatically inserted into this configuration item:
npm install <PACKAGENAME>
yarn add <PACKAGENAME>
When using the --save parameter when installing dependencies, the newly installed npm package will also be written to the dependencies attribute.
npm install --save <PACKAGENAME>The value of this field is an object. Each member of the object consists of the module name and the corresponding version requirement, indicating the dependent module and its version range.
"dependencies": {
"react": "^17.0.2",
"react-dom": "^17.0.2",
"react-scripts": "4.0.3",
},Each configuration here is a key-value pair, key represents the module name, and value represents the module version number. The version number follows the format of"major version number. minor version number. revision number":
-
"Fixed version:" The version 4.0.3 of react-scripts above is the fixed version. Only this specified version will be installed during installation;
-
「tilde:」 For example ~ 4.0.3 means installing the latest version of 4.0.x (not lower than 4.0.3), which means it will not change during installation Major version number and minor version number;
-
「Insert number:」 For example, the version of react above ^17.0.2 means installing the latest version of 17.x.x (not lower than 17.0.2), that is to say, installing The major version number will not be changed. If the major version number is 0, the caret and tilde behave identically;
-
latest: Install the latest version.
Be careful not to put test or transitional dependencies in dependencies to avoid unexpected problems in the production environment.
2. devDependencies
devDependencies declares dependency packages required during the development phase, such as Webpack, Eslint, Babel, etc., to assist development. They differ from dependencies in that they only need to be installed on the development device without running the code in a production environment. These packages are not needed when the package is online, so you can add these dependencies to devDependencies. These dependencies will still be installed and managed when npm install is specified locally, but they will not be installed in the production environment.
When installing packages using npm or yarn, newly installed npm packages will be automatically inserted into this list after specifying the following parameters:
npm install --save-dev <PACKAGENAME>
yarn add --dev <PACKAGENAME>"devDependencies": {
"autoprefixer": "^7.1.2",
"babel-core": "^6.22.1"
}3. peer Dependencies
In some cases, our project and the modules it depends on depend on another module at the same time, but the versions they depend on are different. For example, our project depends on version 1.0 of module A and module B, and module A itself depends on version 2.0 of module B. In most cases this is not a problem and both versions of the B module can coexist and run simultaneously. However, there is a situation where a problem arises, that is, this dependency will be exposed to the user.
The most typical scenario is plug-ins. For example, module A is a plug-in of module B. The B module installed by the user is version 1.0, but the A plug-in can only be used with the B module of version 2.0. At this time, if the user passes the instance of version 1.0 of B to A, problems will occur. Therefore, a mechanism is needed to remind the user during template installation that if A and B are installed together, then B must be a 2.0 module.
The peerDependencies field is used by the plug-in to specify the version of the main tool it requires.
"name": "chai-as-promised",
"peerDependencies": {
"chai": "1.x"
}The above code specifies that when installing the chai-as-promised module, the main program chai must be installed together, and the version of chai must be 1.x. If the dependency specified by the project is version 2.0 of chai, an error will be reported.
It should be noted that starting from npm version 3.0, peerDependencies are no longer installed by default.
4. optionalDependencies
If you need npm to continue running when the package cannot be found or the package installation fails, you can put the package in the optionalDependencies object. The package in the optionalDependencies object will overwrite the package with the same name in dependencies, so you only need to do it in one place. Just set it up.
It should be noted that since the dependencies in optionalDependencies may not be installed successfully, exception handling must be done, otherwise when obtaining this dependency, an error will be reported if it cannot be obtained.
5. bundledDependencies
The above dependency-related configuration items are all an object, and the bundledDependencies configuration item is an array. Some modules can be specified in the array, and these modules will be packaged together when this package is released.
It should be noted that the value in this field array must be a package declared in dependencies and devDependencies.
6. engines
When we maintain some old projects, we may have special requirements for the npm package version or Node version. If the conditions are not met, the project may not be able to run. To make your project work out of the box, you can specify a specific version number in the engines field:
"engines": {
"node": ">=8.10.3 <12.13.0",
"npm": ">=6.9.0"
}It should be noted that engines only serves as a description. Even if the version installed by the user does not meet the requirements, it will not affect the installation of dependent packages.