您好，登录后才能下订单哦！
密码登录
登录注册
点击 登录注册 即表示同意《亿速云用户服务条款》
这篇文章主要讲解了“nodejs中的package.json的作用”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“nodejs中的package.json的作用”吧！
我们在创建 Node.js项目的时候，会遇到 package.json 文件。它是一个 JSON 文件，位于项目的根目录下。
package.json 包含关于项目的重要信息。它包含关于项目的使人类可读元数据（如项目名称和说明）以及功能元数据（如程序包版本号和程序所需的依赖项列表），要想彻底搞懂package.json，我们还得从Node.js的模块（Module）讲起。
在Node.js中，模块可以是一个库或者一个框架，也可以是一个Node.js项目，Node.js项目遵循模块化架构，当我们创建一个Node.js项目的时，这些模块的描述文件被称之为package.json文件。
package.json是Node.js项目中非常重要的配置文件，是一个项目的核心，该文件中跟踪依赖关系和元数据，定义了当前项目所需要的各种模块，以及项目的配置信息，是对项目或者模块包的描述，里面包含许多元信息。
其定义了运行项目所需要的各种依赖和项目的配置信息（比如项目名称、项目版本、项目执行入口文件、执行的脚本、依赖的插件、项目贡献者、许可证以及运行、开发以及有选择地将项目发布到 npm 所需的信息。）。
它是配置和描述如何与程序交互和运行的中心,npm和yarn用它来识别你的项目并了解如何处理项目的依赖关系。
npm cli 也是管理 package.json 的最佳方法，因为它有助于在项目的整个生命周期内生成和更新 package.json 文件。package.json文件就是一个JSON对象，该对象的每一个成员就是当前项目的一项设置。
package.json 会在项目的生命周期中扮演多个角色，其中某些角色仅适用于发布到 npm的软件包，可以启动你的项目、运行脚本、安装依赖项、发布到npm注册表以及许多其他有用的任务。。即使你没有把项目发布到 npm注册表中，或者没有将其公开发布给其他人，那么 package.json 对于开发流程仍然至关重要。
你的项目还必须包含 package.json，然后才能从 npm安装软件包。这也是项目中需要它的主要原因之一。
npm install 命令会根据这个文件下载所有依赖模块。package.json一般都在项目的根目录下。
package.json 文件创建有两种方式，手动创建和自动创建，一般我们使用自动创建较多。
创建项目目录
$mkdir node-demo>cd node-demo>touch package.json
直接在项目根目录下新建一个 package.json 文件，然后输入相关的内容。
{
"name": "express-admin",
"version": "1.0.0",
"description": "Express Admin",
"keywords": [
"server",
"express",
"compression"
],
"homepage":"https://gitee.com/xunzhaotech/express-admin.git",
"bugs":"https://github.com/owner/project/issues",
"license": "MIT",
"author": {
"name": "Amber luyb",
"email": "luyb@xunzhaotech.com",
"url": "https://www.xunzhaotech.com"
},
"contributors": [
{
"name": "Amber luyb",
"email": "luyb@xunzhaotech.com",
"url": "https://gitee.com/xunzhaotech/express-admin.git"
}
],
"funding": [
{
"type" : "individual",
"url" : "http://example.com/donate"
},
"http://example.com/donateAlso",
{
"type" : "patreon",
"url" : "https://www.patreon.com/my-account"
}
],
"files":[".git",
"CVS",
".svn",
".hg",
".lock-wscript",
".wafpickle-N",
".*.swp",
".DS_Store",
"._*",
"npm-debug.log",
".npmrc",
"node_modules",
"config.gypi",
"*.orig,"],
"main": "index.js",
"browser":"",
"bin": {
"myapp": "./cli.js"
},
"man": [
"./man/foo.1",
"./man/bar.1"
],
"repository": {
"type": "git",
"url": "https://gitee.com/xunzhaotech/express-admin.git"
},
"scripts": {
"docs:dev": "vuepress dev docs",
"docs:build": "vuepress build docs",
"server": "node server.js",
"start": "node index.js",
"dev": "nodemon",
"lint": "eslint **/*.js"
},
"config": {
"port": "8080"
},
"devDependencies": {
"eslint": "^7.22.0",
"mockjs": "^1.1.0",
"nodemon": "^2.0.7",
"vuepress": "^1.8.2"
},
"dependencies": {
"body-parser": "^1.19.0",
"compression": "^1.7.4",
"cookie-parser": "^1.4.5",
"debug": "^4.3.1",
"express": "^4.17.1",
"express-session": "^1.17.1"
},
"peerDependencies": {
"tea": "2.x"
},
"peerDependenciesMeta": {
"soy-milk": {
"optional": true
}
},
"bundledDependencies": [
"renderized",
"super-streams"
],
"optionalDependencies":{},
"engines": {
"npm": "~1.0.20"
},
"os": [
"darwin",
"linux"
],
"cpu": [
"!arm",
"!mips"
],
"private": false,
"publishConfig":{},
"workspaces": [
"./packages/*"
]
}当我们新建一个名称为 xz-nuxt-admin， 在项目根目录下执行 yarn init -y 或 npm init -y 命令后，也可以输入 npm init或yarn init -y这个命令采用互动方式，要求用户回答一些问题，然后根据提示一步步输入相应的内容完成后即可在项目目录下会新增一个基本的 package.json文件。所有问题之中，只有项目名称（name）和项目版本（version）是必填的，其他都是选填的。内容如下：
{
"name": "my-test", # 项目名称
"version": "1.0.0", # 项目版本（格式：大版本.次要版本.小版本）
"author": "", # 作者
"description": "", # 项目描述
"main": "index.js", # 入口文件
"scripts": { # 指定运行脚本命令的 npm 命令行缩写
"test": "echo \"Error: no test specified\" && exit 1"
},
"keywords": [], # 关键词
"license": "ISC" # 许可证
}我们知道 package.json 中包含的一些最常见和重要的字段，用来管理项目的配置信息或发布到 npm，而其他一些则可以帮助 npm CLI 运行应用程序或安装依赖项。实际的字段比我们所介绍的要多，你可以在它的文档中了解其余字段，但以下的是必须要了解的 package.json 属性。
package.json 中有非常多的配置项，其中必须填写的两个字段分别是 name 字段和 version 字段，它们是组成一个 npm 模块的唯一标识。
name 字段定义了模块的名称，其命名时需要遵循官方的一些规范和建议：
项目/模块名称，长度必须小于等于214个字符，不能以"."(点)或者"_"(下划线)开头，不能包含大写字母。
模块名会成为模块 url、命令行中的一个参数或者一个文件夹名称，任何非 url 安全的字符在模块名中都不能使用（我们可以使用 validate-npm-package-name 包来检测模块名是否合法）。
语义化模块名，可以帮助开发者更快的找到需要的模块，并且避免意外获取错误的模块；
若模块名称中存在一些符号，将符号去除后不得与现有的模块名重复。
name 字段不能与其他模块名重复，我们可以执行以下命令查看模块名是否已经被使用：
npm view <packageName>或者，我们也可以去 npm 上输入模块名，如果搜不到，则可以使用该模块名。
在package.json文件中，版本是非常重要的一个概念，npm 包中的模块版本都需要遵循 SemVer 规范，该规范的标准版本号采用 X.Y.Z 的格式，其中 X、Y 和 Z 均为非负的整数，且禁止在数字前方补零：
X 是主版本号(major)：第一位就是主要版本号。一般来说，重大功能的更新，或功能的添加又不能向后兼容的情况会提升该版本号。
Y 是次版本号(minor)：中间那一位是指次要版本号。一般来说，一些功能的添加，但又能向后兼容，这种更新会提升该版本号。
Z 是修订号(patch)：最后一位就是补丁版本号。一般来说，如果是项目的一些BUG修复，会将该版本号提升。
当某个版本改动比较大、并非稳定而且可能无法满足预期的兼容性需求时，我们可能要先发布一个先行版本。
先行版本号可以加到主版本号.次版本号.修订号的后面，通过 - 号连接一连串以句点分隔的标识符和版本编译信息：
内部版本(alpha)
公测版本(beta)
正式版本的候选版本rc（即 Release candiate）
我们可以执行以下命令查看模块的版本：
$npm view <packageName> version # 查看某个模块的最新版本 $npm view <packageName> versions # 查看某个模块的所有历史版本
可选字段是除去必填字段需要补充的项目信息
description：字段用于添加模块的描述信息，便于用户了解该模块，是一个字符串。它可以帮助人们在使用npm search时找到这个包。
keywords 项目关键字，是一个字符串数组。用于给模块添加关键字。它可以帮助人们在使用npm search时找到这个包。
当我们使用 npm 检索模块时，会对模块中的 description 字段和 keywords 字段进行匹配，写好 package.json中的 description 和 keywords 将有利于增加我们模块的曝光率。
dependencies：字段指定了项目运行所依赖的模块（生产环境下，项目运行所需依赖）。
devDependencies：指定项目开发所需要的模块（开发环境下，项目所需依赖）。
说明：
我们在使用vue框架开发一个程序，开发阶段需要用到webpack来构建你的开发和本地运行环境。所以vue一定要放到dependencies里，因为以后程序到生产环境也要用。webpack则是你用来压缩代码，打包等需要的工具，程序实际运行的时候并不需要，所以放到devDependencies里就可以了。或者我们在写程序要用ES6标准，浏览器并不完全支持，所以你要用到babel来转换代码，babel放devDependencies。程序里有用到开源组件，比如你想用antd，antd要放dependencies。
scripts 字段是 package.json 中的一种元数据功能，它接受一个对象，对象的属性为可以通过 npm run 运行的脚本，值为实际运行的命令（通常是终端命令），如：
"scripts": {
"dev": "nuxt",
"build": "nuxt build",
"start": "nuxt start",
"generate": "nuxt generate"
},将终端命令放入 scripts 字段，既可以记录它们又可以实现轻松重用。
main 字段是 package.json 中的另一种元数据功能，它可以用来指定加载的入口文件。假如你的项目是一个 npm 包，当用户安装你的包后，const ModuleName = require('module-name') 返回的是 main 字段中所列出文件的 module.exports 属性。当不指定main 字段时，默认值是模块根目录下面的index.js 文件。
files 字段用于描述我们使用 npm publish 命令后推送到 npm 服务器的文件列表，如果指定文件夹，则文件夹内的所有内容都会包含进来。我们可以查看下载的 antd 的 package.json 的files 字段，内容如下：
"files": [ "dist", "lib", "es" …… ],
可以看到下载后的 antd 包是下面的目录结构中包含了 /dist/"lib/es文件，另外，我们还可以通过配置一个 .npmignore 文件来排除一些文件， 防止大量的垃圾文件推送到 npm 上。
一般公司的非开源项目，都会设置 private 属性的值为 true，这是因为 npm 拒绝发布私有模块，通过设置该字段可以防止私有模块被无意间发布出去。
使用 os 属性可以指定模块适用系统的系统，或者指定不能安装的系统黑名单（当在系统黑名单中的系统中安装模块则会报错）
"os" : [ "darwin", "linux" ] # 适用系统 "os" : [ "!win32" ] # 黑名单
在 node 环境下可以使用 process.platform 来判断操作系统
我们可以用 cpu 字段更精准的限制用户安装环境
"cpu" : [ "x64", "ia32" ] # 适用 cpu "cpu" : [ "!arm", "!mips" ] # 黑名单
在 node 环境下可以使用 process.arch 来判断 cpu 架构
防止因node 版本不同，导致会出现很多奇奇怪怪的问题（如某些依赖安装报错、依赖安装完项目跑不起来等）。
"engines": {
"node": ">= 8.16.0",
"npm": ">= 6.9.0"
},需要注意的是，engines属性仅起到一个说明的作用，当用户版本不符合指定值时也不影响依赖的安装
bin 字段用来指定各个内部命令对应的可执行文件的位置。主要应用在脚手架搭建中，当package.json 提供了 bin 字段后，即相当于做了一个命令名和本地文件名的映射。 当用户安装带有 bin 字段的包时，
如果是全局安装，npm 将会使用符号链接把这些文件链接到/usr/local/node_modules/.bin/；
如果是本地安装，会链接到./node_modules/.bin/。
如果要使用 mfd-cli 作为命令时，可以配置以下 bin 字段：
"bin": {
"mfd-cli": "./bin/cli.js"
}上面代码指定，mfd-cli 命令对应的可执行文件为 bin 子目录下的 cli.js，因此在安装了 mfd-cli 包的项目中，就可以很方便地利用 npm执行脚本：
"scripts": {
start: 'node node_modules/.bin/mfd-cli'
}这里看起来和 vue create/create-react-app之类的命令不太一样？是因为：当需要 node 环境时就需要加上 node 前缀如果加上 node 前缀，就需要指定mfd-cli 的路径 -> node_modules/.bin，否则 node mfd-cli会去查找当前路径下的 mfd-cli.js，这样肯定是不对。若要实现像 vue create/create-react-app之类的命令一样简便的方式，则可以在上文提到的 bin 子目录下可执行文件cli.js 中的第一行写入以下命令：#!/usr/bin/env node这行命令的作用是告诉系统用 node 解析，这样命令就可以简写成 mfd-cli 了。
当我们使用 create-react-app 脚手架搭建的 React 项目，默认是使用内置的 webpack 配置，当package.json 中不配置 homepage 属性时，build 打包之后的文件资源应用路径默认是/。
一般来说，我们打包的静态资源会部署在 CDN 上，为了让我们的应用知道去哪里加载资源，则需要我们设置一个根路径，这时可以通过 package.json 中的 homepage 字段设置应用的根路径。
当我们设置了 homepage 属性后：
{
"homepage": "https://xxxx.cdn/project-name",
}打包后的资源路径就会加上 homepage 的地址：/project-name/bundle.js
author：项目开发者，它的值是你在npmjs.org网站的有效账户名，遵循“账户名<邮件>”的规则，例如：xunzhaotech@aliyun.com。
private：是否私有，设置为 true 时，npm 拒绝发布。
license：软件授权条款，让用户知道他们的使用权利和限制。
bugs：bug 提交地址。
contributors：项目贡献者 。
repository：项目仓库地址。
module：是以 ES Module(也就是 ES6)模块化方式进行加载，因为早期没有 ES6 模块化方案时，都是遵循 CommonJS 规范，而 CommonJS 规范的包是以 main 的方式表示入口文件的，为了区分就新增了 module 方式，但是 ES6 模块化方案效率更高，所以会优先查看是否有 module 字段，没有才使用 main 字段。
eslintConfig：EsLint 检查文件配置，自动读取验证。
browserslist：供浏览器使用的版本列表。
style：供浏览器使用时，样式文件所在的位置；样式文件打包工具parcelify，通过它知道样式文件的打包位置。
为什么有了package.json，还需要package-lock.json文件呢，当node_modules文件夹并不存在或被删除时，需要用到npm install重新装载全部依赖时，通过package-lock.json可以直接表明下载地址和相关依赖，相对下载速度也更快，也不容易报错。
感谢各位的阅读，以上就是“nodejs中的package.json的作用”的内容了，经过本文的学习后，相信大家对nodejs中的package.json的作用这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。