この記事では、Node.js プロジェクトの package.json ファイル、その機能、作成方法、package.json、package.json と package- の管理方法について説明します。ロック.jsonの違い。
フロントエンド エンジニアリングと自動化の発展に伴い、現在のフロントエンドおよび完全な Node.js プロジェクトではモジュール開発がトレンドになっています package.json ファイルはどこにでもあります。まず、これはプロジェクトのルート ディレクトリにあり、次に、node_modules にも頻繁に現れます。では、このファイルは何のためにあり、どのような役割を果たしているのでしょうか? 今日はそれを公開します。 [推奨学習: "nodejs チュートリアル "]
Node.js プロジェクトを作成するとき、package.json ファイルが表示されます。これは、プロジェクトのルート ディレクトリにある JSON ファイルです。
package.json には、プロジェクトに関する重要な情報が含まれています。これには、プロジェクトに関する人間が判読できるメタデータ (プロジェクト名や説明など) と機能メタデータ (パッケージのバージョン番号やプログラムに必要な依存関係のリストなど) が含まれています。 Node.js モジュールから始めましょう。
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 は開発プロセスにとって依然として重要です。
npm からパッケージをインストールするには、プロジェクトに package.json も含まれている必要があります。これが、プロジェクトでこれが必要となる主な理由の 1 つです。
npm install コマンドは、このファイルに基づいてすべての依存モジュールをダウンロードします。 package.json は通常、プロジェクトのルート ディレクトリにあります。
package.json ファイルを作成するには、手動作成と 自動作成の 2 つの方法があります。通常は自動作成を使用します。もっと見る
プロジェクト ディレクトリを作成します
$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/*" ] }
が作成されます。プロジェクト ルート ディレクトリで
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 字段定义了模块的名称,其命名时需要遵循官方的一些规范和建议:
name 字段不能与其他模块名重复,我们可以执行以下命令查看模块名是否已经被使用:
npm view <packageName>
或者,我们也可以去 npm 上输入模块名,如果搜不到,则可以使用该模块名。
当某个版本改动比较大、并非稳定而且可能无法满足预期的兼容性需求时,我们可能要先发布一个先行版本。
先行版本号可以加到主版本号.次版本号.修订号的后面,通过 - 号连接一连串以句点分隔的标识符和版本编译信息:
我们可以执行以下命令查看模块的版本:
$npm view <packageName> version # 查看某个模块的最新版本 $npm view <packageName> versions # 查看某个模块的所有历史版本
可选字段是除去必填字段需要补充的项目信息
说明:
我们在使用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 字段的包时,
如果要使用 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
package.json があるのに package-lock.json ファイルが必要なのはなぜですかNode_modules フォルダーが存在しないか削除され、npm install を使用してすべての依存関係をリロードする必要がある場合、package-lock.json を通じてダウンロード アドレスと関連する依存関係を直接指定できます。ダウンロード速度も速くなり、エラーを報告するのは簡単ではありません。
プログラミング関連の知識について詳しくは、プログラミング ビデオをご覧ください。 !
以上がこの記事では、nodejs の package.json について説明します。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。