フロントエンド JavaScript ハウスキーパー package.json

今日は、フロントエンドのpackage.jsonファイルの構成を見てみましょう。これらの構成を完全に理解することで、開発効率を向上させ、プロジェクトを標準化するのに役立ちます。記事にはたくさんの内容が含まれているので、まずは勉強用に保存しておくことをお勧めします！

すべてのフロントエンドプロジェクトには、プロジェクトの構成ファイルであるpackage.jsonファイルがあります。一般的な構成には、プロジェクトの起動の構成、コマンドのパッケージ化、依存パッケージの宣言などが含まれます。 package.jsonファイルは JSON オブジェクトであり、その各メンバーは現在のプロジェクトの設定です。フロントエンドの管理者として、 package.jsonのどの構成が日常の開発に密接に関係しているのでしょうか?このファイルを詳しく見てみましょう。

新しいプロジェクトをビルドする場合、スキャフォールディングは、プロジェクトのルートディレクトリにあるpackage.jaon構成ファイルを初期化するのに役立ちます。プロジェクトがreact scaffold (create-react-app) を使用して初期化されると、 package.jsonファイルの内容は次のようになります。

{
  "名前": "my-app",
  "バージョン": "0.1.0",
  「プライベート」：true、
  「依存関係」: {
    "@testing-library/jest-dom": "^5.14.1",
    "@testing-library/react": "^11.2.7",
    "@testing-library/ユーザーイベント": "^12.8.3",
    "反応": "^17.0.2",
    "反応dom": "^17.0.2",
    "react-scripts": "4.0.3",
    "ウェブバイタル": "^1.1.2"
  },
  「スクリプト」: {
    "開始": "react-scripts 開始",
    "ビルド": "react-scriptsビルド",
    "テスト": "react-scripts テスト",
    "eject": "react-scripts eject"
  },
  "eslintConfig": {
    「拡張」: [
      「リアクトアプリ」、
      「react-app/jest」
    ]
  },
  「ブラウザリスト」: {
    "生産"： [
      ">0.2%",
      「死んでない」
      「op_mini すべてではない」
    ]、
    "発達"： [
      「最後の 1 つの Chrome バージョン」、
      「Firefoxの最新1バージョン」
      「最後の 1 つの Safari バージョン」
    ]
  }
}

新しいプロジェクトをローカルにクローンする場合は、 npm install (yarn install) コマンドを実行して、プロジェクトに必要な依存ファイルをインストールする必要があります。このコマンドを実行すると、 package.jsonファイル内の構成情報、つまり構成プロジェクトに必要な実行環境と開発環境に応じて、必要なモジュールが自動的にダウンロードされます。

package.json 内の一般的な構成項目は次のとおりです。

1. 必須属性

package.jsonで最も重要な 2 つのフィールドはnameとversionです。これらは両方とも必須です。これらがないと、 npm installコマンドを正常に実行できません。 npm は、 package.jsonファイルが名前とバージョン番号を一意の識別子として使用することを指定します。

1. 名前

name分かりやすく、プロジェクトの名前であり、文字列です。

nameフィールドに名前を付けるときは、次の点に注意する必要があります。

名前は 214 文字以下で、「.」または「_」で始まってはならず、大文字を含めることもできません (これは、パッケージがnpmで公開されると、このプロパティに基づいて独自のURLが取得されるため、 non-url-safeを含めることができないためです)。
名前は、モジュールをインポートするrequire ("") に引数として渡すことができるため、できるだけ短く意味のあるものにする必要があります。
名前は他のモジュールと同じにすることはできません。npm npm viewコマンドを使用して、モジュール名が重複していないかどうかを確認できます。重複していない場合は、404 エラーメッセージが表示されます。

npmパッケージに対応するパッケージがある場合は、パッケージの詳細情報が表示されます。

実際、私たちが開発するプロジェクトの多くはnpmで公開されていないため、名前が標準であるかどうかはそれほど重要ではない可能性があり、プロジェクトの正常な動作には影響しません。 npmで公開する必要がある場合は、 nameフィールドが要件を満たしている必要があります。

2. バージョン

versionフィールドは、プロジェクトパッケージのバージョン番号 (文字列) を示します。各プロジェクトの変更後、リリースされる直前に、プロジェクトのバージョン番号を同期的に変更する必要があります。

バージョン番号の使用仕様は次のとおりです。

バージョン番号は、セマンティックバージョニング 2.0.0 仕様に従って、メジャーバージョン番号.マイナーバージョン番号.リビジョン番号の形式で命名されます。通常、メジャーバージョン番号の変更は機能上の大きな変更を意味し、マイナーバージョン番号の変更は新機能の追加を意味し、リビジョン番号の変更はバグの修正を意味します。
バージョンに大きな変更があり、不安定で、予想される互換性要件を満たさない可能性がある場合は、プレリリースバージョンをリリースする必要があります。プレリリースバージョンはバージョン番号の後に追加され、ドットで区切られた識別子とバージョンコンパイル情報は「-」記号で接続されます。つまり、内部バージョン (alpha)、パブリックベータバージョン (beta)、候補バージョン (rc、リリース候補) となります。

react を例にとると、次のコマンドを使用して npm パッケージのバージョン情報を表示できます。

// 最新バージョンを表示 npm view react version
// すべてのバージョンを表示 npm view react バージョン

2 番目のコマンドを実行すると、結果は次のようになります。

2. 説明情報

package.jaonには、プロジェクトパッケージの説明情報に関連する 5 つの設定フィールドがあります。それぞれのフィールドの意味を見てみましょう。

1. 説明

descriptionフィールドは、このプロジェクトパッケージを説明するために使用されます。これは、他の開発者がnpm検索でプロジェクトパッケージを見つけられるようにする文字列です。

2. キーワード

keywordsフィールドは、このプロジェクトパッケージのキーワードを表す文字列配列です。 descriptionと同様に、プロジェクトパッケージの露出を高めるために使用されます。

以下は eslint パッケージの説明とキーワードです。

3. 著者

authorその名前が示すように、プロジェクトパッケージの作成者を示します。 2 つの形式があり、1 つは文字列形式です。

「著者」: 「CUGGZ <[email protected]> (https://juejin.cn/user/3544481220801815)」

もう 1 つはオブジェクト形式です。

"著者"： {
  「名前」:「CUGGZ」、
  「メール」：「[email protected]」、
  「URL」:「https://juejin.cn/user/3544481220801815」
}

4. 貢献者

contributors 、プロジェクトパッケージの貢献者を表します。author とは異なり、このフィールドはすべての貢献者を含む配列です。また、次の 2 つの書き方があります。

「貢献者」: [
  「CUGGZ0 <[email protected]> (https://juejin.cn/user/3544481220801815)」、
  「CUGGZ1 <[email protected]> (https://juejin.cn/user/3544481220801815)」
 ]

「貢献者」: [
  {
   「名前」:「CUGGZ0」、
   「メール」：「[email protected]」、
   「URL」:「https://juejin.cn/user/3544481220801815」
 },
  {
   「名前」:「CUGGZ1」、
   「メール」：「[email protected]」、
   「URL」:「https://juejin.cn/user/3544481220801815」
 }
 ]

5. ホームページ

homepageプロジェクトのホームページアドレスであり、文字列です。

6. リポジトリ

repository 、コードが保存されているリポジトリのアドレスを表し、通常は 2 つの形式で記述されます。 1 つ目は文字列形式です。

「リポジトリ」: 「https://github.com/facebook/react.git」

さらに、バージョン管理システムを明示的に設定することもできます。この場合は、オブジェクトの形式で設定します。

「リポジトリ」: {
  「タイプ」: 「git」、
  「URL」: 「https://github.com/facebook/react.git」
}

7. バグ

bugs 、プロジェクト内の問題を送信するためのアドレスを表します。このフィールドは、問題を送信するためのアドレスとフィードバック用の電子メールアドレスを追加できるオブジェクトです。

「バグ」: { 
  「URL」: 「https://github.com/facebook/react/issues」、
  「メール」：「[email protected]」
}

最も一般的なbugs Githubのissuesページにあります。上記はreactのissuesページのアドレスです。

3. 依存関係の構成

通常、プロジェクトは 1 つ以上の外部依存パッケージに依存します。依存パッケージのさまざまな用途に応じて、次の 5 つのプロパティで構成できます: dependencies 、 devDependencies 、 peerDependencies 、 bundledDependencies 、 optionalDependencies 。それぞれの属性の意味を見てみましょう。

1. 依存関係

dependenciesフィールドは、プロジェクトの運用環境に必要な依存パッケージを宣言します。 npmまたはyarnを使用してnpmパッケージをインストールすると、 npm パッケージがこの構成項目に自動的に挿入されます。

npm install <パッケージ名>
yarn add <パッケージ名>

依存関係をインストールするときに--saveパラメータを使用すると、新しくインストールされたnpmパッケージもdependenciesプロパティに書き込まれます。

npm install --save <パッケージ名>

このフィールドの値は、メンバーがモジュール名と対応するバージョン要件で構成され、依存モジュールとそのバージョン範囲を示すオブジェクトです。

「依存関係」: {
   "反応": "^17.0.2",
   "反応dom": "^17.0.2",
   "react-scripts": "4.0.3",
},

ここでの各構成はkey-value値) であり、 keyモジュール名を表し、 valueモジュールのバージョン番号を表します。

バージョン番号は、メジャーバージョン番号.マイナーバージョン番号.リビジョン番号の形式に従います。

修正バージョン:上記のreact-scriptsバージョン 4.0.3 は修正バージョンです。インストール時にはこの指定されたバージョンのみがインストールされます。
チルダ:たとえば、~4.0.3 は最新バージョンの 4.0.x (4.0.3 以上) をインストールすることを意味し、インストール中にメジャーバージョン番号とマイナーバージョン番号は変更されません。
番号を挿入:たとえば、上記の react バージョン ^17.0.2 は、17.xx の最新バージョン (17.0.2 未満ではない) をインストールすることを意味し、インストール中にメジャーバージョン番号は変更されません。メジャーバージョン番号が 0 の場合、キャレットとチルダ文字の動作は同じになります。
最新:最新バージョンをインストールします。
実稼働環境で予期しない問題を回避するために、 dependenciesにテスト依存関係や移行依存関係を含めないようにすることが重要です。

2. 開発依存関係

devDependencies 、開発を支援するために、 Webpack 、 Eslint 、 Babelなど、開発フェーズ中に必要な依存パッケージを宣言します。これらは、開発マシンにインストールするだけでよく、運用環境でコードを実行する必要がないという点でdependenciesとは異なります。これらのパッケージはパッケージ化や起動時には必要ないので、これらの依存関係をdevDependenciesに追加できます。これらの依存関係は、ローカルでnpm install指定すると引き続きインストールおよび管理されますが、実稼働環境ではインストールされません。

npmまたはyarnを使用してパッケージをインストールする場合、次のパラメータを指定すると、新しくインストールされた npm パッケージがこのリストに自動的に挿入されます。

npm install --save-dev <パッケージ名>
yarn add --dev <パッケージ名>

「devDependencies」: {
  "自動プレフィックス": "^7.1.2",
  "バベルコア": "^6.22.1"
}

3. ピア依存関係

場合によっては、プロジェクトとそれが依存するモジュールの両方が別のモジュールに依存しているものの、依存するバージョンが異なる場合があります。たとえば、プロジェクトはモジュール A とモジュール B のバージョン 1.0 に依存しており、モジュール A 自体はモジュール B のバージョン 2.0 に依存しています。ほとんどの場合、これは問題ではなく、モジュール B の両方のバージョンが共存して同時に実行できます。ただし、この依存関係がユーザーに公開されると問題が発生します。

最も一般的なシナリオはプラグインです。たとえば、モジュール A はモジュール B のプラグインです。ユーザーがインストールした B モジュールはバージョン 1.0 ですが、A プラグインは B モジュールのバージョン 2.0 でのみ使用できます。このとき、ユーザーが B のバージョン 1.0 のインスタンスを A に渡すと、問題が発生します。したがって、テンプレートをインストールするときに、A と B が一緒にインストールされる場合、B は 2.0 モジュールである必要があることをユーザーに通知するメカニズムが必要です。

peerDependenciesフィールドは、プラグインが必要なメインツールのバージョンを指定するために使用されます。

"名前": "約束通りのチャイ",
「ピア依存関係」: {
   "チャイ": "1.x"
}

上記のコードは、 chai-as-promisedモジュールをインストールするときに、メインプログラム chai も一緒にインストールする必要があり、chai のバージョンが 1.x である必要があることを指定しています。プロジェクトが chai バージョン 2.0 の依存関係を指定している場合、エラーが報告されます。

npm バージョン 3.0 以降では、 peerDependenciesデフォルトでインストールされなくなったことに注意してください。

4. オプションの依存関係

パッケージが見つからないoptionalDependenciesやパッケージのインストールに失敗した場合にもnpm実行を継続する必要がある場合は、パッケージをoptionalDependenciesオブジェクトに配置することができます。optionalDependencies オブジェクト内のパッケージは、 dependencies内の同じ名前のパッケージを上書きするため、1 か所で設定するだけで済みます。

optionalDependencies内の依存関係が正常にインストールされない可能性があるため、例外処理を実行する必要があることに注意してください。そうしないと、この依存関係を取得できない場合にエラーが報告されます。

5. バンドルされた依存関係

上記の依存関係関連の構成項目はすべてオブジェクトですが、 bundledDependencies構成項目は配列であり、このパッケージがリリースされるときに一緒にパッケージ化されるいくつかのモジュールを指定できます。

このフィールド配列の値は、 dependenciesおよびdevDependenciesで宣言されたパッケージである必要があることに注意してください。

6. エンジン

古いプロジェクトをメンテナンスする場合、 npmパッケージのバージョンや Node のバージョンに特別な要件がある場合があります。条件が満たされない場合、プロジェクトを実行できない可能性があります。プロジェクトをすぐに動作させるには、 enginesフィールドに特定のバージョン番号を指定します。

「エンジン」: {
 "ノード": ">=8.10.3 <12.13.0",
  "npm": ">=6.9.0"
}

注:エンジンは説明のみを目的としています。ユーザーがインストールしたバージョンが要件を満たしていない場合でも、依存パッケージのインストールには影響しません。

4. スクリプトの設定

1. スクリプト

scripts は、 package.jsonに組み込まれたスクリプトエントリです。これはkey-valueペアの構成です。キーは、npm run を通じて実行できる実行可能コマンドです。基本的なscriptsコマンドを実行するだけでなく、pre とpostを組み合わせて、事前操作と事後操作を完了することもできます。

まず、 scriptsのセットを見てみましょう。

「スクリプト」: {
 "dev": "ノードindex.js",
  "predev": "ノードbeforeIndex.js",
  "postdev": "ノード afterIndex.js"
}

これら 3 つの js ファイルにはそれぞれconsoleがあります。

// インデックス.js
console.log("スクリプト: index.js")
// beforeIndex.js
console.log("scripts: index.js の前")
// afterIndex.js
console.log("scripts: index.js の後")

npm run dev コマンドを実行すると、出力は次のようになります。

スクリプト: index.js の前
スクリプト: index.js
スクリプト: index.js 以降

ご覧のとおり、3 つのコマンドがすべて実行され、実行順序はpredev→dev→postdevです。 scriptsコマンドに特定のシーケンスがある場合は、これらの 3 つの構成項目を使用して実行コマンドを個別に構成できます。

スクリプトプロパティを構成することで、いくつかの一般的な操作コマンドを定義できます。

「スクリプト」: {
  "dev": "webpack-dev-server --inline --progress --config build/webpack.dev.conf.js",
  「開始」: 「npm run dev」、
  "ユニット": "jest --config test/unit/jest.conf.js --coverage",
  "テスト": "npm 実行ユニット",
  "lint": "eslint --ext .js,.vue src テスト/ユニット",
  "ビルド": "ノードビルド/build.js"
}

これらのスクリプトはコマンドラインアプリケーションです。これらは、 npm run XXXまたはyarn XXXを呼び出すことで実行できます。ここで、 XXX はコマンドの名前です。たとえば、 npm run dev 。コマンドには任意の名前を使用でき、スクリプトは任意のものを使用できます。

このフィールドを適切に使用することで、開発効率が大幅に向上します。

2. 設定

configフィールドは、以下に示すように、 scriptsランタイムの構成パラメータを構成するために使用されます。

「設定」: {
 「ポート」: 3000
}

npm run startを実行すると、ポートフィールドはnpm_package_config_port環境変数にマップされます。

コンソールログ(process.env.npm_package_config_port) // 3000

ユーザーはnpm config set foo:port 3001コマンドを実行してポート値を上書きできます。

5. ファイルとディレクトリ

package.json内のファイルとディレクトリに関連するプロパティを見てみましょう。

1. メイン

mainフィールドは、ロードするエントリファイルを指定するために使用され、 browserとNode環境の両方で使用できます。プロジェクトをnpmパッケージとして公開する場合、 requireを使用して npm パッケージをインポートすると、main フィールドにリストされているファイルのmodule.exportsプロパティが返されます。このフィールドが指定されていない場合、デフォルトはプロジェクトルートディレクトリのindex.jsになります。見つからない場合はエラーが報告されます。

このフィールドの値は文字列です:

"メイン": "./src/index.js",

2. ブラウザ

browserフィールドでは、 browser環境でのnpmパッケージのエントリファイルを定義できます。 npm パッケージが Web 側でのみ使用され、サーバー側での使用が厳しく禁止されている場合は、 browserを使用してエントリファイルを定義します。

"ブラウザ": "./src/index.js"

3. モジュール

moduleフィールドでは、 browser環境とノード環境の両方で使用できるnpmパッケージのESM仕様エントリファイルを定義できます。 npm パッケージが ESM 準拠のパッケージをエクスポートする場合は、 moduleを使用してエントリファイルを定義します。

"モジュール": "./src/index.mjs",

注: .js ファイルではcommonJS標準構文(require('xxx'))が使用され、.mjs ファイルでは ESM 標準構文 (import 'xxx') が使用されます。

上記の 3 つのエントリファイルの構成は、特に使用シナリオによって異なります。 Web 環境では、 loader を使用して ESM (ES モジュール) をロードする場合、これら 3 つの構成のロード順序はbrowser→module→mainとなります。 requireを使用してCommonJSモジュールをロードする場合、ロード順序はmain→module→browserとなります。

Webpackプロジェクトをビルドするときにはターゲットオプションがあり、デフォルトでは Web、つまり Web アプリケーションがビルドされます。ノードプロジェクトなどの同型プロジェクトをコンパイルする必要がある場合は、ビルドのためにwebpack.config.jsのターゲットオプションを node に設定するだけで済みます。 Node 環境で CommonJS モジュールまたは ESM をロードする場合、メインフィールドのみが有効になります。

4. ビン

bin フィールドは、各内部コマンドに対応する実行可能ファイルの場所を指定するために使用されます。

「ビン」: {
  "someTool": "./bin/someTool.js"
}

ここで、 someToolコマンドに対応する実行可能ファイルは bin ディレクトリ内のsomeTool.jsであり、 someTool.jsシンボリックリンクnode_modules/.bin/someToolを作成します。実行時にnode_modules/.bin/ディレクトリがシステムの PATH 変数に追加されるため、npm を実行するときに、パスなしでコマンドを通じてこれらのスクリプトを直接呼び出すことができます。したがって、次のように短縮できます。

スクリプト: {  
  開始: './node_modules/bin/someTool.js ビルド'
}

// 省略形スクリプト: {  
  開始: 'someTool ビルド'
}

node_modules/.bin/ディレクトリ内のすべてのコマンドはnpm run [command] 形式を使用して実行できます。

上記の構成では、 package.jsonにローカルファイル名にマップされる bin フィールドが提供されます。npm パッケージは、このファイルをグローバルインポートのプレフィックス/修正にリンクします。または、このプロジェクトで使用するためにローカルのnode_modules/.bin/ファイルにリンクします。

5. ファイル

ファイル構成は、 npmパッケージを依存パッケージとしてインストールするときに指定する必要があるファイルのリストを記述する配列です。 npmパッケージが公開されると、files で指定されたファイルがnpmサーバーにプッシュされます。フォルダーが指定されている場合は、フォルダーの下にあるすべてのファイルが送信されます。

「ファイル」: [
    "ライセンス"、
    「Readme.md」、
    "index.js",
    「lib/」
 ]

送信したくないファイルがある場合は、プロジェクトのルートディレクトリに新しい.npmignoreファイルを作成し、送信する必要のないファイルを記述して、ジャンクファイルがnpmにプッシュされるのを防ぐことができます。このファイルの形式は.gitignoreに似ています。このファイルに書き込まれたファイルは、ファイル属性に書き込まれている場合でも除外されます。たとえば、このファイルに次のように記述できます。

ノードモジュール
.vscode

建てる

.DS_ストア

6. 男性

man コマンドは Linux のヘルプコマンドです。このコマンドを使用すると、Linux のコマンドヘルプ、設定ファイルヘルプ、プログラミングヘルプなどの情報を表示できます。 node.jsモジュールがグローバルコマンドラインツールである場合、man 属性を使用して、man コマンドがpackage.json内を検索するドキュメントアドレスを指定できます。

"男"： [
 "./man/npm-access.1",
 "./man/npm-audit.1"
]

man フィールドには 1 つ以上のファイルを指定できます。man {パッケージ名} を実行すると、ドキュメントの内容がユーザーに表示されます。

注記：

man ファイルは数字で終わる必要があり、圧縮されている場合は .gz サフィックスを使用できます。この番号は、ファイルがどの man セクションにインストールされているかを示します。man ファイル名がモジュール名で始まっていない場合は、インストール時にモジュール名のプレフィックスが追加されます。

上記の構成では、次のコマンドを使用してドキュメントを表示できます。

マニュアル npm-access
男npm監査

7. ディレクトリ

directoriesフィールドは、プロジェクトディレクトリを指定するために使用されます。 Node.js モジュールはCommonJSモジュール化仕様に基づいて実装されており、CommonJS 仕様に厳密に従う必要があります。パッケージプロジェクト記述ファイルpackage.jsonに加えて、モジュールディレクトリには次のディレクトリも含まれている必要があります。

bin: 実行可能なバイナリファイルを保存するディレクトリ
lib: jsコードが保存されるディレクトリ
doc: ドキュメントを保存するためのディレクトリ
test: ユニットテストケースコードを保存するディレクトリ
...

実際のプロジェクトディレクトリでは、この仕様に従って名前を付けられない場合があります。そのため、 directoriesフィールドで各ディレクトリに対応するファイルパスを指定できます。

「ディレクトリ」: {
    "bin": "./bin",
    "lib": "./lib",
    "ドキュメント": "./doc",
    「テスト」「./テスト」、
    "男": "./男"
},

この属性には実際には実用的な用途はありませんが、将来的にはより有意義な用途が生まれる可能性も否定できません。

6. リリース構成

npmプロジェクトパッケージのリリースに関連する設定を見てみましょう。

1. プライベート

private フィールドは、誤ってプライベートライブラリを npm サーバーに公開することを防ぎます。このフィールドを true に設定するだけです:

"プライベート": true

2. グローバルを好む

preferGlobalフィールドは、ユーザーがモジュールをグローバルモジュールとしてインストールしない場合に true に設定されていると警告が表示されることを示します。これは実際にユーザーによる部分的なインストールの実行を妨げるものではなく、誤解を防ぐための注意喚起のみを提供します。

"preferGlobal": 真

3. 設定を公開する

publishConfig構成は、モジュールが公開されたときに有効になり、公開時に構成項目のコレクションを設定するために使用されます。モジュールをデフォルトで最新としてマークしたくない場合、またはモジュールをパブリックリポジトリに公開したくない場合は、ここでタグまたはリポジトリアドレスを設定できます。より詳細な設定については、 npm-configを参照してください。

通常、 publishConfigはprivateと一緒に使用されます。モジュールを特定のnpmリポジトリにのみ公開したい場合は、次のように設定できます。

「プライベート」：true、
「公開構成」: {
  "タグ": "1.1.0",
  「レジストリ」: 「https://registry.npmjs.org/」、
  「アクセス」：「公開」
}

4. オス

os フィールドを使用すると、 npmパッケージを使用できるオペレーティングシステムと使用できないオペレーティングシステムを設定できます。 Linux でのみ実行されるnpmパッケージを開発する場合、不要な例外を回避するために、 Windowsシステムを使用しているユーザーはそれをインストールしないことをお勧めします。この場合、os 構成を使用できます。

"os" ["linux"] // 適用可能なオペレーティングシステム "os" ["!win32"] // 無効なオペレーティングシステム

5. CPU

この構成は OS 構成に似ています。CPU CPU使用すると、ユーザーのインストール環境をより正確に制限できます。

"cpu" ["x64", "AMD64"] // 適用可能なCPU
"cpu" ["!arm", "!mips"] // 無効なCPU

ご覧のとおり、ブラックリストとホワイトリストの違いは、ブラックリストの前に「!」が付いていることです。

6. ライセンス

licenseフィールドは、ソフトウェアのオープンソース契約を指定するために使用されます。オープンソース契約では、コードを取得した後に他者が持つ権利、コードに対して実行できる操作、禁止されている操作について説明します。

一般的なプロトコルは次のとおりです。

MIT:ユーザーがプロジェクトのコピーに著作権表示とライセンス表示を含める限り、ユーザーはコードに対して何でもすることができ、開発者は一切の責任を負う必要はありません。
Apache: MIT に似ていますが、貢献者がユーザーに特許ライセンスを提供するための条件も含まれています。
GPL:プロジェクトコードを変更したユーザーは、ソースコードまたはバイナリコードを再配布するときに、その変更を公開する必要があります。

フィールドは次のように宣言できます。

「ライセンス」: 「MIT」

7. サードパーティの構成

package.jsonファイルには、 Babel 、 ESLintなどのコマンド固有の構成も格納できます。それぞれに、 eslintConfig 、 babelなどの固有のプロパティがあります。これらはコマンド固有であり、使用方法については対応するコマンド/プロジェクトのドキュメントに記載されています。よく使用されるサードパーティの構成項目をいくつか見てみましょう。

1. タイピング

Typings フィールドは、TypeScript エントリファイルを指定するために使用されます。

"タイピング": "types/index.d.ts",

このフィールドの機能はmain機能と同じです。

2. eslint設定

eslint の設定は、別の設定ファイル.eslintrc.jsonに記述することも、 package.jsonファイルのeslintConfig設定項目に記述することもできます。

"eslintConfig": {
      「ルート」：真、
      "env": {
        "ノード": 真
      },
      「拡張」: [
        「プラグイン:vue/必須」、
        「eslint:推奨」
      ]、
      「ルール」: {},
      "パーサーオプション": {
        "パーサー": "babel-eslint"
     },
}

3. バベル

Babel は、Babel のコンパイル構成を指定するために使用されます。コードは次のとおりです。

「バベル」：{
 "プリセット": ["@babel/preset-env"],
 「プラグイン」: [...]
}

4. 解凍

このフィールドを使用して、 npm上のすべてのファイルに対して CDN サービスを有効にします。CND サービスは unpkg によって提供されます。

"unpkg": "dist/vue.js"

5. lintステージ

lint-staged 、Git ステージングファイルに対してlinters実行するツールです。設定後、ファイルが変更されるたびにすべてのファイルに対して lint チェックを実行できます。通常はgitHooksと組み合わせて使用されます。

「lintステージング」: {
 "*.js": [
   "eslint --fix",
    「git 追加」
  ]
}

lint-stagedを使用する場合、各コードの送信では現在変更されているファイルのみがチェックされます。

6. gitフック

gitHooks 、コミット前に ESlint チェックを実行するためのフックを定義するために使用されます。 lint コマンドを実行すると、一時保存領域内のファイルが自動的に修復されます。修復されたファイルはステージング領域に保存されないため、 git addコマンドを使用して修復されたファイルをステージング領域に再度追加する必要があります。 pre-commitコマンドを実行した後、エラーがなければ、 git commit コマンドが実行されます。

"gitフック": {
 「事前コミット」: 「lint ステージング」
}

ここでは、上記のlint-stagedと連携してコードをチェックします。

7. ブラウザリスト

browserslistフィールドは、サポートされているブラウザとバージョンを指定するために使用されます。これは、 Babel 、 Autoprefixer 、およびその他のツールによって、必要なpolyfillとfallbackターゲットブラウザに追加するために使用されます。たとえば、上記の例ではこのフィールドの値は次のようになります。

「ブラウザリスト」: {
  "生産"： [
    ">0.2%",
    「死んでない」
    「op_mini すべてではない」
  ]、
  "発達"： [
    「最後の 1 つの Chrome バージョン」、
    「最新の Firefox バージョン 1」、
    「最後の 1 つの Safari バージョン」
  ]
}

ここでは、運用環境と開発環境のブラウザ要件を定義するオブジェクトが指定されます。上記のdevelopmentでは、開発環境でサポートされているchrome 、 Firefox 、 safariブラウザの最新バージョンを指定しています。このプロパティは、異なるフロントエンドツール間でターゲットブラウザーとノードバージョンを共有するためBabel構成ツールです。Babel やAutoprefixerなど、多くのフロントエンドツールで使用されます。

フロントエンド JavaScript バトラー package.json に関するこの記事はこれで終わりです。フロントエンドバトラー package.json に関するより関連性の高いコンテンツについては、123WORDPRESS.COM の以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: