[TIL]package.json

package.json

他者による管理とインストールが容易なnode package導入文書

package.jsonはこんな顔をしている
npm Docsの説明によれば、
package.jsonは

プロジェクト依存パッケージのリスト

は、プロジェクトのバージョン

を示します.

は、他の環境で再生できます.

は、他の開発者が簡単に使用できるようにします.
次のような役割を果たす

オープンソースパッケージエコシステムリスト

プロジェクト依存性管理リスト

オープンソースパッケージエコシステム配置リスト

このように整理することができます

NPM(Node Package Manager)

npmはnodeです.jsのパッケージマネージャ、nodeでもあります.jsのオープンソース生態系のために
npmコマンドでオープンソースパッケージをダウンロードまたは配布できます

yarn

似たような包装マネージャーの糸があります.
Facebookが作成したJavaScriptパッケージマネージャです.
糸が速いと言っていますが、私はいつもこの糸を使っています.
npmとは差が少ない
違いは、パッケージの追加インストール時に(npm)installではなく(糸)addを使用することです.
npmインストールで使用可能$ npm install -g yarn npmよりもyarnの方が好きなので、今後ブログでもyarnの方が多く取り上げられます.

package.jsonの使い方

パッケージを使用するフォルダに移動し、端末で$ yarn initまたは$npm initコマンドを使用してパッケージ化します.jsonのプロトタイプを作成できます

次の問題を開始します.初期値を設定したり、企業を基本型に分割したりできます.

初期値を設定できる項目をフィールドと呼びます
ひとつひとつ見る

1.「name」と「version」

nameパッケージの名前を指定します.
設置されていないのでわかりませんが、名前には独自のルールがあるそうです.
基本ルール

は小文字で記入しなければなりません.

は単語、単語でなければなりません.

mayは、ハイフンおよびアンダースコア、-(ハイフン)または(ベースコード)を含むことができる.

version
上記のフォーマットを使用して、セマンティックバージョン管理ガイドに従います.
バージョンおよびネーミングのルールは、会社または団体によって異なります.
確かなのは.nameとversionの2つの分野が必要です
このフィールドがない場合は、パッケージをインストールできません.

2. 'main'

このフィールドは端末の初期設定では見つかりませんが、設定できます.

入り口ですmainはモジュールのIDであり、パッケージのエントリポイントとなる.
たとえば、ユーザーがfooというパッケージをインストールし、require(「foo」)を介してモジュールをインポートすると、mainとして指定されたモジュールのエクスポートオブジェクトが返されます.
このように見ることができます

パッケージルートの相対パスとして指定する必要があります.指定されていない場合は、ルートフォルダのindexです.デフォルトはjsです.
私たちが例題を勉強している間にindexはjsというファイル名で中枢ファイルを作成する場合が多いのは、そのためらしい

3. 'scripts'

スクリプトでよく使用されるshellコマンドを別名(別名)と書くと、コマンドの代わりに便利に使用できます.

nodemonのように煩わしい長い命令を書く代わりに、ありがたい存在です.
端末を飛ばし、$yarn devまたは$npm devと書けば、$nodemon index.jsと同様のコマンドを送信することができる.

4. 'keywords', 'author', 'license', 'description'

「keywords」:キーワードを文字列配列として記述します.
descriptionと同様に、npmで検索するとリストに表示され、パッケージの検索と理解を支援します.
「author」:発行者用に作成されたフィールドです.複数のユーザーを表示するには、「貢献者」フィールドに入力する必要があります.
この2つは実際にはデプロイメント者用と言えるフィールドです
「license」:licenseを指定して、ユーザーがパッケージを使用する権限と制限を解除する必要があります.
「description」:文字列で記述されたパケットの説明.
npmで検索されると、パッケージを見つけて理解するのに役立つリストに表示されます.
それ以外にも、「funding」のように細かい説明がある分野もありますが、私たちが使うときは実際には必要ないので、スキップしましょう.

5.'dependencies'&'devDependencies'

ユーザーにとって、この2つの分野は実際にはコア分野です.
「dependencies」と「devDependencies」
これは、プロジェクトに依存するパッケージを統合管理するためのフィールドと言える.
プロジェクトが正常に動作するには、どのライブラリが必要かを詳細に説明します.
また、このフィールドを使用する場合は、コラボレーションなどの複数の人が同時に作業する必要がある場合は、ファイルを使用して$yarn installを行うだけです.
同じ開発環境を迅速に構築できるという利点があります.

{
  "dependencies": {
    "hexo": "^5.0.0",
    "hexo-deployer-git": "^3.0.0",
    "hexo-generator-archive": "^1.0.0",
    "hexo-generator-category": "^1.0.0",
    "hexo-generator-feed": "^3.0.0"
    // ...
  }
}

{
  "devDependencies": {
    "@testing-library/jest-dom": "^5.11.4",
    "@testing-library/react": "^11.1.0",
    "@testing-library/user-event": "^12.1.10",
    "alex": "^8.2.0",
    "eslint": "^7.30.0",
    "lerna-changelog": "~0.8.2"
    // ...
  }
}

依存:本番環境でアプリケーションに必要なパッケージ.

「devDependencies」:必要なパッケージのみをローカルで開発およびテストします.

それ以外にも多くのフィールドが存在します
パッケージ関連ページを指すフィールドもあれば、エラーやホットスポットを提示できるurlやemailを書くフィールドもあります.
小包を感じに来たはずだjsonのフィールドには、パケット・ユーザーが気を遣う必要がない部分を示すフィールドがたくさんあります.
開発パッケージの開発者でない場合は、すべてのフィールドを理解する必要はありません.
パッケージを使用してWebまたはアプリケーションを開発するユーザー
上記のフィールドのversionとdependencies
その中で「dependencies」は重要で、彼らのバージョン情報を間違えたり漏らしたりしないことが重要です.
でも….
参考にした開発ログで「いつか開発パッケージの開発者になるかもしれない」という言葉を見ました.
実はパッケージを開発するとは思わなかった.今こそJavaScriptでキィキィキィキィキィキィキィキィキィキィキィキィキィキィキィキィキィキィキィキィキィキィキィキィキィキィ
その言葉から開発ログマスターの自信と野望を感じた.
私もいつかソフトウェアパッケージを開発する開発者になりたいです.

Reference

[NodeJS]みんな知ってるけどみんな知らないパッケージjson
分かってから書こうjson
dependenciesとdevDependenciesの違い