npm は、フロントエンド開発者によって広く使用されているパッケージ管理ツールです。プロジェクトでは、package.json を使用して、プロジェクトが依存する npm パッケージの構成を管理します。 package.json は、プロジェクトのパッケージの依存関係を記述するだけでなく、「セマンティック バージョン管理ルール」を使用してプロジェクトの依存パッケージのバージョンを示すこともできるため、ビルドを他の開発者とより適切に共有できるようになります。再利用。 。 この記事は主に、最新の npm およびノード バージョンと組み合わせた最近の実践から始まり、package.json の一般的な構成と標準化された package.json の作成方法を紹介します。
npm init
を渡します。
その後、 3 が生成されます。 your directory. directories/files, node_modules, package.json and package.lock.json. package.json の内容は次のとおりです:
{
"name": "プロジェクト名",
「バージョン」：「1.0.0」、
"description": "プロジェクトの説明",
"メイン": "app.js",
「スクリプト」: {
"test": "echo "Error: no test specified" && exit 1",
}、
「著者」：「著者名」、
「ライセンス」：「ISC」、
"依存関係": {
"Dependency1"： "^1.4.0"、
"Dependency2"： "^1.5.2"
}
上記からわかるように、
package.json にはプロジェクト自体のメタデータに加えて、プロジェクトのサブ依存情報 (依存関係など) が含まれています。
npm init 中に、package.json ファイルが生成されるだけでなく、package-lock.json ファイルも生成されることがわかりました。では、なぜPackage.jsonをクリアするときにPackage-lock.jsonファイルを生成する必要があるのですか？基本的に、package-lock.json ファイルはバージョンをロックするためのものです。実際のインストールでは、バージョンが以降である限り、package.json で指定されるサブ npm パッケージは次のようになります。 react, package.json is satisfied. requirements.これは、同じ package.json ファイルによれば、2 回インストールされたサブ依存関係のバージョンの一貫性が保証できないことを意味します。
パッケージロックファイルは以下のようになっており、サブ依存関係 dependency1 でバージョンを詳細に指定します。ロックバージョンの役割を果たします。
{
"name": "プロジェクト名",
"version": "1.0.0",
"ロックファイルのバージョン": 1、
「必要」：本当、
"依存関係": {
"依存関係1": {
「バージョン」：「1.4.0」、
「解決」：
"https://registry.npmjs.org/dependency1/-/dependency1-1.4.0.tgz"、
"誠実さ"：
"sha512-a+uqth4kgzg/slgvfbzdhpgru7aaqommqrhjnxhrzickfut91brvhnnt58cmwu9psbbbv3pdczuhbvxudih2mta =="
}、
"Dependency2"：{
「バージョン」： "1.5.2"、
「解決」：
"https://registry.npmjs.org/dependency2/-/dependency2-1.5.2.tgz",
"誠実さ"：
"sha512-WOn21V8AhyE1QqVfPIVxe3tupJacq1xGkPTB4iagT6o+P2cAgEOOwIxMftr4+ZCTI6d551ij9j61DFr0nsP2uQ=="
}
}
2. この章では、package.json で一般的に使用される構成属性について説明します。名前、バージョンなどの属性は単純すぎるため、1 つずつ紹介しません。この章では、主にスクリプト、ビン、ワークスペースのプロパティを紹介します。
uses the script tag in npm to define a script. Whenever npm run is specified, a shell script will be automatically created. What needs to be noted here is that the new shell created by npm run will store node_modules/.bin in theローカルディレクトリにサブディレクトリを追加します。
これは、現在のディレクトリの node_modules/.bin サブディレクトリ内のすべてのスクリプトを、パスを追加せずにスクリプト名を使用して直接呼び出すことができることを意味します。たとえば、現在のプロジェクトの依存関係にesbuildが含まれている場合は、esbuild xxxを直接書き込むだけです。
{
// ...
「スクリプト」: {
"build": "esbuild index.js",
}
} {
// ...
「スクリプト」: {
"build": "./node_modules/.bin/esbuild index.js"
}
}上面两种写法是等价的。
bin 属性は、実行可能ファイルをグローバル環境にロードするために使用されます。bin フィールドを含む npm パッケージが指定されると、そのファイルはグローバル環境にロードされ、エイリアスを介してファイルを実行できます。
たとえば、 @bytepack/cliのnpmパッケージ：
"bin"：{
"bytepack": "./bin/index.js"
}、 @bytepack/cliがグローバルにインストールされると、 bytepack -v
などのbytepackを介して対応するコマンドを直接実行できます
// 1.11.0を
グローバルにインストールしていない場合、プロジェクトのnode_module/.binディレクトリに自動的に接続されます。与前面介绍的script标签中所说的一致，可以直接用别名来使用。
在项目过大的时候，最近越来越流行monorepo。モノリポについては、初期の頃は、yarn ワークスペースを使用していましたが、npm はワークスペースを正式にサポートし、トップレベルのルート パッケージの下で複数のサブパッケージを管理する方法の問題を解決しました。 in the local file system. In the workspaces declaration directory The package will be soft-linked to the node_modules of the top-level root package.
直接以官网的例子来说明：
{
"name": "my-project",
"ワークスペース": [
「パッケージ/A」
】
my-project という名前の npm パッケージには、
ワークスペースによって構成されたディレクトリがあります。
。 +-- パッケージ.json + - index.js ` - パッケージ +-a |。 `-JSON
とMy-Projectという名前のトップレベルのルートパッケージには、サブパッケージがあります。現時点では、NPMパッケージがnode_modulesにインストールされている場合は、ローカルパッケージを指します
。 +-Node_Modules | + - package-lock.json + - package.json ` - パッケージ +-a | `--
上記の
package.json--packages/a -> ../packages/a は、
node_modules の a からローカル npm パッケージへのソフト リンクを指します
package.json 環境関連の属性を持つ共通の環境。上記はブラウザ環境とノード環境の 2 つのカテゴリに分かれています。 次に、package.json の環境に関連する構成プロパティを見てみましょう。環境の定義は次のように簡単に理解できます。
には、commonjs、CMD、UMD、AMD および ES モジュールが含まれます。 当初、node では commonjs フィールドのみがサポートされていましたが、node13.2.0 以降、node は ES モジュール仕様を正式にサポートします。 Package.jsonでフィールドを使用して、NPMパッケージが続くモジュラー仕様を宣言できます。
//package.json
{
名前: 「あるパッケージ」、
タイプ：「モジュール」||「CommonJS」
type が指定されていない場合、type のデフォルト値は commonjs であることに注意
してください
type フィールドで値を module として指定する場合は、ESModule 仕様が使用されること
が推奨されます
。 type field is specified, all .js in the directory will
Files ending with the suffix follow the modularization specification specified by type.
In addition to type, which can specify the modularization specification, the modularization specification followed by the file is specified through the suffix of the file. Files ending with .mjs are the ESModule specifications used. The .cjs ending follows the commonjs specification
In addition to type, package.json also has three fields: main, module and browser npmパッケージのエントリーファイルを定義します。
これら 3 つのフィールドの使用シナリオと、これら 3 つのフィールドが同時に存在する場合の優先順位を見てみましょう。 demo1というNPMパッケージがあると仮定しましょう
----- dist |--index.browser.js | -INDEN.BROWSER.MJS | - index.js |-- index.mjs
其package.json中同时指定了main,module和browser这3个字段，
"main": "dist/index.js", // main
"module": "dist/index.mjs", // モジュール
// ブラウザは、main/module フィールドに対応するマッピング オブジェクトとして定義することも、文字列 "browser" として直接定義することもできます: {
"./dist/index.js": "./dist/index.browser.js", // browser+cjs
"./dist/index.mjs"： "./dist/index.browser.mjs" // browser+mjs
}、
// "browser": "./dist/index.browser.js" // ブラウザーがビルドされ、デフォルトで使用されます。 たとえば、プロジェクト内でこの npm パッケージを参照するとします。
上記をビルドした後、
「demo」からデモをインポートします。
ビルド ツール、モジュールを介したコード 読み込みシーケンスは次のとおりです:
ブラウザ + mjs > モジュール > ブラウザ + cjs > main
この読み込みシーケンスは、webapck、esbuild などのほとんどのビルド ツールのデフォルトの読み込みシーケンスです
。この読み込み順序は、対応する構成を介して変更できますが、ほとんどのシナリオでは、デフォルトの読み込み順序に従っています。
package.json でエクスポート フィールドが定義されている場合、このフィールドで定義されているコンテンツは npm パッケージの実際の完全なエクスポートであり、メイン フィールドやファイル フィールドよりも優先順位が高くなります。
例えば：
{
「名前」：「PKG」、
「エクスポート」：{
"。"： "./main.mjs"、
"./foo": "./foo.js"
}
} import { something } from "pkg"; // from "pkg/main.mjs" const { something } = require("pkg/foo"); //上記の例より
require("pkg/foo.js")エクスポートは、異なるパスで輸出を定義できるようです。如果存在exports后，以前正常生效的file目录到处会失效，比如require('pkg/package.json')，因为在exports中没有指定，就会报错。
exports还有一个最大的特点，就是条件引用，比如我们可以根据不同的引用方式或者模块化类型，来指定npm包引用不同的入口文件。
// package.json
{
"名前":"パッケージ",
「メイン」： "./main-require.cjs"、
「エクスポート」：{
"インポート": "./main-module.js",
「要求」：「./main-require.cjs」
}、
「タイプ」：「モジュール」
}上記の例では、
const p = require（ 'pkg'）を介して
「./main-require.cjs」を参照する
場合。合格する場合：
「PKG」からpをインポートすると、
参照は「./main-module.js」です
。 but also higher than the module and browser fields.
package.jsonの依存関係に関連する構成プロパティには、依存関係、開発、ピア依存関係、Peerdependenciesmetaなどが含まれます。
依存関係はプロジェクトの依存関係であり、devDependency は開発に必要なモジュールであるため、開発プロセス中に必要に応じてインストールすることで開発効率を向上させることができます。ここで注意する必要があるのは、自分のプロジェクトでできる限り標準的に使用するように努めることです。たとえば、webpack、babel などは開発依存関係であり、プロジェクト自体の依存関係に含めないでください。
依存関係 依存関係と devDependency に加えて、この記事では、peerDependency とpeerDependencyMeta に焦点を当てます。
ピア依存関係は package.json 内の依存関係であり、これにより、コア ライブラリが複数回ダウンロードされ、コア ライブラリのバージョンが統一される問題を解決できます。
//パッケージ/pkg ----- node_modules | -npm-a-> react、react-domに依存します | -npm-b-> react、react-domに依存します |--index.js
たとえば、上記の例で、サブ npm パッケージ a と b が両方とも React と React-dom からのものである場合、サブ NPM パッケージ a と b の package.json で PeerDependies を宣言すると、 b, the corresponding Dependencies will not be reinstalled.
注意すべき2つのポイントがあります。NPM7
ん
。
"反応": "^16.8.3 || ^17 || ^18"
}、
「PeerDependenciesMeta」：{
「React-dom」：{
「オプション」: true
}、
「React-Native」：{
「オプション」：本当です
}
}这里指定了"react-dom","react-native"在peerDependenciesMeta中，且为可选项，因此如果项目中检测没有安装"react-dom"和"react-native"都不会报错。
実際にpeerDependencyMetaを通じて制限を解除したことは注目に値しますが、多くの場合、制限がAまたはBのいずれかになるシナリオがあります。たとえば、上記の例では、必要なのは「react-dom」と「react-native」です。そして、1つをインストールする必要がありますが、実際、上記のステートメントを通じてこのプロンプトを達成することはできません。
package.json には、tsc で使用される type、ビルド ツールで使用される SideEffects、git で使用される husky、eslint で使用される eslintIgnore など、多くのスリーパーティ属性もあります。 extensions is for specific Development tools are meaningful and I won’t give examples here.