<aside> ◻️ L I F E

<aside> 📝 2022/12/25 知識系はツェッテルカステンベースで再整理中（✅  再整理完了 ‣ ）

</aside>

• 自身について
• 学び（一般）
• 学び（IT / プログラミング）
• 学び（デザイン / マーケティング）
• ライフログ </aside>

<aside> 💡 目次

</aside>

<aside> 📆 2021/01/27 書いた 自分がよく使う yarn の機能について

</aside>

yarn についての歴史と概要

• 機能的には npm とほぼ同じ
• Facebook がメンテナンスしている
• package-lock.json が登場する前、バージョン固定に課題感を持った Facebook が開発した
  • 昔はnpm-shrinkwrap.json というのがあった
  • いまは package-lock.json が登場して、デフォルトで生成されるようになった。ここに関する機能の差分はほぼなし
• npm より気持ちインストールが早い気がする

プロジェクト内でのバージョンの固定 yarn.lock

• npm でいう package-lock.json と同じ役割のもの 複数人開発でのメンバー間でのバージョン差分をなくすのに使える
• git 管理する ‣
• ファイルの中身の例
• version
  • package.json で固定バージョンを指定していない場合、こちらでバージョンが固定される
• resolved
  • どこからパッケージがダウンロードされるかが記述される
  • npm もしくは github package registry の場合が多い
• dependencies
  • 依存パッケージがの依存しているパッケージ（ややこしい）が表示されている
  • デフォルトだと、依存パッケージの依存パッケージは node_modules 直下に生成される（要確認）
    • 複数の依存パッケージで同じ依存パッケージを使用している場合（バージョンが異なる場合）には、依存パッケージ内に node_modules が生成される
  • yarn --flat コマンドを使用すると、プロジェクト全体でパッケージのバージョンが1つになる（全てルートの node_modules 内にパッケージが flat に存在するようになる）
    • 使ったこと無い

依存パッケージのバージョンアップ yarn upgrade

• yarn upgrade で依存パッケージのアップグレードを行う
• yarn upgrade-interactive で対話形式でアップグレードを行う
  • モノレポ構成で開発してるときにめっちゃ便利

依存パッケージのローカル参照 yarn link

• パッケージを分割して開発するときに使う
  • 自分たちはよく使う 複数パッケージで共通で使用する型定義やコンポーネントを分割して管理している
• パッケージAがパッケージBに依存しているとき、パッケージBを公開せずとも、ローカルのパッケージBを参照するようにすることができる
  • 実体はそこには存在せず、参照のみ存在する Symbolic link （略して Symlink）と呼ばれるようになる
• 使い方は、パッケージB内で yarn link コマンドを実行、パッケージA内で、yarn link [パッケージBの名前] でリンクできる

設定ファイル .yarnrc

• 普通に使用している分には意識しなくて大丈夫
• 設定ファイルが npm と異なる。npm の場合は .npmrc だが yarn の場合は .yarnrc
• GitHub Package Registry を使うとき（GitHub Actions 経由でパッケージ公開するとき）に少し面倒
  • 2021/01/27 時点で yarn とうまく馴染んでいない感じだった （.yarnrc の設定を読めない？）
• ワークアラウンドとして、GitHub Actions 内で、 .npmrc ファイルを生成し、そこに設定を書き込むようにしている
  • （もっと良い方法あったら知りたい）
  • コード的には以下のような感じ

モノレポ構成でアプリケーションを作る yarn workspace

• 複数のパッケージを1つのパッケージにまとめて管理できる yarn workspace という機能が提供されている

  • モノレポ構成でアプリケーションを作成するときに便利

• 親の package.json に以下のプロパティを追加するだけで有効化される

  • private: true は必須 誤って公開されてしまうのを防ぐ目的
  • workspaces は、子のパッケージ名を指定する。
    • packages/ というディレクトリを作って、その中に置くのが慣習
    • packages/* みたいな感じでワイルドカードで指定も可能

  {
    "private": true,
    "workspaces": ["workspace-a", "workspace-b"]
  }
  

  • 子の package は "name": "workspace-b" みたいな感じになる。

• 依存パッケージのインストールはどこでも良いのでいつもどおり yarn install を実行すれば良い

  • いい感じに依存を整理してくれて、node_modules が親に生成される（巻き上げ hoisting と呼ばれることが多い）
  • 巻き上げたくないやつは nohoist オプションを付ける
    • パッケージ内に複数のパッケージが存在するとエラーになるパッケージがあったりする（React とか）

• 子で共通の依存パッケージを使用している場合は、巻き上げて、同じパッケージを参照するようになる（ボリュームの削減）