npm, yarn による zero install 戦略 - from scratch
jsconf.eu 2019 に行ってきました。 特に npm や yarn の今後の話とそもそも Registry をどうしていくか、の話があったのでお知らせします。 そもそも Registry をどうしていくかについては次のエントリで話します。 tink: A Next Generation Package Manager npm の次のコマンドラインツールである tink が紹介されていました。 github.com presentation: github.com video: www.youtube.com そもそも npm の仕組み ローカル依存ファイルを読む (package.json, package-lock.json, shrinkwrap.json) 存在しないパッケージのメタデータをfetchする 木構造を計算して、実行する（npm v3 以降だとflattenする
Lerna を使って、 Babel や React が採用している monorepo を試してみる - Qiita
monorepo とは 複数の npm package を 単一の git repository で管理すること 例えば Babel では、 100 以上の npm package が単一の git repository で管理されている https://github.com/babel/babel/tree/master/packages package 毎に repository を作る場合と比較した Pros & Cons Babel の repository のドキュメントから抜粋 Pros: lint, build, test, release のプロセスを共通化できる package をまたがった修正が容易になる issue 管理を一元化できる 開発環境の構築が簡単になる テストも package をまたいで実行でき、複数 package が絡む不具合の検知が容易になる Con
[Node.js] プライベート NPM モジュールを任意の package.json で指定する | DevelopersIO
車輪開発大好きおたいがです。こんにちは。（挨拶） Node.js のアプリケーション開発において、以下のような構造があると仮定します。複数のアプリケーションディレクトリ (app_1, app_2, app_3) と、各アプリケーションから参照できる共通モジュールディレクトリ (common) の例です。( 各ディレクトリはそれぞれ Git リポジトリにて管理されているものとします ) ├─ common ├─ app_1 ├─ app_2 ├─ app_3 このとき上記 common の内容が Java の JAR ファイルや、Flash の SWC のように圧縮できたり、各アプリケーションプロジェクトから参照できたりすれば楽なのですが、そのようなことはできないので、common をプライベート NPM モジュールにして、各アプリケーションの package.json の depende
![[Node.js] プライベート NPM モジュールを任意の package.json で指定する | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/6c530ac8058349624341e83c42577b3ded88f3e6/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2013%2F09%2Fnodejs.png)
npmで名前空間を持ったモジュールを公開する方法(scoped modules)
npmにモジュールを公開することは多くなってると思いますが、今までのnpmだと名前は早い者勝ちでした。 最近npm Private Modulesというprivateで扱えるモジュールを有料でサポートしましたが、これはscoped modulesをprivateで扱う時だけ有料でpublicで公開する時は無料で行えます。 scoped modulesというのは、@username/project-name という感じで、@ユーザー名がパッケージ名に入るので異なるユーザー間では重複しません。 The npm Blog — solving npm’s hard problem: naming packages 公開手順 実際にscoped modulesをpublicに公開する手順としては、 npm init --scope=<npmユーザ名> パッケージの名前が@<npmユーザ名>/パッケー
セキュリティ インシデント flatmap-stream@0.1.1 と npm-run-all での対応 - Qiita
人気のある npm パッケージ event-stream (DL数: 2M/週) が悪意ある攻撃に利用されるというセキュリティ インシデントがありました。 私が管理する npm-run-all (DL数: 440K/週) も間接的に event-stream に依存していたため、インシデントの詳細と私の対応について触れておきます。 何をすべき? あなたのプロジェクトが event-stream に依存している場合は、この依存を削除し、代替手段を探すと良さそうです。event-stream の作者は、このパッケージをメンテナンスしないと明言しています。ただ、これだけ騒ぎになったので、信用できる誰かが引き継ぐ可能性はあります。 [編集(2018/11/30)] 現在は npm 社がパッケージ管理を引き継いでいます。ただ、リポジトリは凍結されており、今後変更されることはないでしょう。 次に、あな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
