newmoでは、フロントエンド、バックエンド、iOSやAndroidなどのモバイルアプリをすべて同じリポジトリで管理するmonorepoを採用しています。 monorepoを採用することで、アプリケーション間で共通のコードを共有することができたり、CIの管理が楽になったり、他のチームのコードを見るのにわざわざリポジトリをcloneする必要がなくなります。 また、monorepoを採用することで、アプリケーションが利用しているパッケージ(ライブラリやツール)のバージョンを1つだけにするOne Version Ruleが実装できます。 One Version Rule One Version Ruleは、monorepo内のパッケージのパッケージのバージョンを1つだけにするルールです。 The One Version Rule | Google Open Source One Versio
niという npm/yarn/pnpm/bun を同じコマンドでインストール/アンストールコマンドを実行できるツールがあります。 antfu/ni: 💡 Use the right package manager 仕組み的には、各パッケージのロックファイルやCorepackで決められたpackageManagerフィールドの値から、どのパッケージマネージャを使うかを判断しています。 たとえば、package-lock.jsonがあるプロジェクトなら npm を使ってるので、niコマンドは npm のコマンドを実行します。 また、packageManagerフィールドがyarn@<version>になっている場合は、niコマンドは yarn コマンドを実行します。 なぜこういうツールが必要になるかというと、npm や yarn などのパッケージマネージャは、それぞれのパッケージマネージャの
pnpm の新規ユーザーから、pnpm が生成する node_modules の奇妙な構造についてよく聞かれます。 なぜ平坦な構造を使用しないのでしょうか。 依存のさらにその依存はどこにあるのでしょうか。 この記事では、npm や Yarn の生成するフラットな node_modules に馴染みのある読者を想定しています。 npm が v3 からフラットな node_modules を採用する必要があった理由については、 なぜ pnpm が必要なのでしょうか (英語) を参照してください。 では、なぜ pnpm は通常とは異なる構造の node_modules を使用するのでしょう。 試しに 2 つのディレクトリを作成して、片方には npm add express を、もう一方には pnpm add express を実行してみてください。 npm の方のディレクトリにある node_m
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
