JSRは別のパッケージマネージャーではなく、新しいツールです

xguru · 2024-04-26T10:43:02+09:00

JSR - JavaScriptパッケージ共有のための新しいレジストリここ数年、yarnやpnpmのような新しいパッケージマネージャーが登場し、パッケージのダウンロード方法を改善してきたしかし、JavaScriptエコシステムの中核であるnpmパッケージレジストリは、ほとんど進化してこなかった最後に注目すべきアップデートは、数年前に追加された"files"タブだった活発に進化していることで知られるJavaScript言語が、逆説的にも時代遅れの配布モデルに足を引っ張られているように見える JavaScriptモジュールシステムの問題点 Nodeが作られた当時、JavaScript用の標準モジュールシステムは存在しなかったため、npmレジストリとNodeは根本的な欠陥があるCommonJS(require)システムを標準として採用したこれはブラウザでは動作しないシステムだった今からほぼ10年前の2015年に、言語自体がESモジュール(import)構文を採用した今日では、ほとんどのJavaScriptはESモジュールを使って書かれているが、これらのモジュールを配布する方法は依然として複雑である特にTypeScriptが関わる場合はなおさらであるこのエコシステムにおける明白なギャップから、JSRが生まれた JSRは別のパッケージマネージャーではなく、サーバーサイドランタイム、ブラウザ、さまざまなツール間でJavaScriptとTypeScriptを共有する方法を刷新するために設計された、変革的なレジストリである JSRの特徴と利点 JSRは、長年開発者を悩ませてきた複雑さを簡素化することで、コード配布プロセスを根本から改善する ESM専用でTypeScriptファーストなJSRは、package.json設定や迷路のようなtsconfigコンパイラオプションの煩雑な調整を不要にするパッケージスコアリングシステムを通じて、JSRはコード配布のベストプラクティスを促進する Dartコミュニティのpub.devと同様に、エクスポートされる各シンボルについて包括的なJSDocドキュメントを含むパッケージに、より高いスコアを与える GoやRustのような他の現代的なプログラミングエコシステムで見られるように、JSRはデフォルトで自動ドキュメント生成機能を提供する npmとの関係 JSRはレジストリであり、npmレジストリ向けの別のクライアントではないただし、これはnpmのすべてを捨てたり、分離されたJavaScriptモジュールエコシステムへ移行したりしなければならないという意味ではない JSRはnpmレジストリを補完するよう設計されており、npmを置き換えることを目的としていない JSRパッケージはnpmパッケージに依存できる（例: このパッケージ参照）また、JSRパッケージは既存のnpm中心のソフトウェアでも利用できる JSR自体がnpm互換のtarballを配布するnpmレジストリ（npm.jsr.ioでアクセス可能）として動作するためこれにより、JSRパッケージをnpm、yarn、またはpnpmを使うあらゆるソフトウェアに組み込み、プライベートレジストリと統合できる JSRが配布するnpm tarballは最適化されているセキュリティ重視 Denoでは、JavaScript開発においてセキュリティを最優先課題としているどのレジストリも公開されたすべてのコードを包括的に監視することはできないが、JSRは発行者に関する透明性を提供し、発行プロセスを保護する GitHub ActionsとOIDCトークンを統合することで、JSRはソフトウェアアーティファクトのためのSupply-chain Levelsを利用して、高度で検証可能な来歴証明を生成し、それをSigstoreに保存するこれはコードの真正性を保証するだけでなく、開発者が実装する内容に対する信頼と責任を確立する JavaScript開発の中心地 JavaScriptは、多くのプログラマーにとって共通言語であり、普遍的でアクセスしやすいこの言語には、開発者が不要な複雑さなしに成果物を共有できる中央ハブ、いわばタウンスクエアが必要である私たちは、JavaScriptが今後長年にわたってソフトウェア開発の中心であり続けると信じており、JSRはその継続的な重要性を支えることを目指している JSRは単なるエコシステム内の別のツールではなく、JavaScriptとTypeScriptの配布について私たちが考える方法の根本的な変化を示している

(deno.com)

7 ポイント投稿者 xguru 2024-04-26 | 3件のコメント | WhatsAppで共有

JSR - JavaScriptパッケージ共有のための新しいレジストリ

ここ数年、yarnやpnpmのような新しいパッケージマネージャーが登場し、パッケージのダウンロード方法を改善してきた
しかし、JavaScriptエコシステムの中核であるnpmパッケージレジストリは、ほとんど進化してこなかった
- 最後に注目すべきアップデートは、数年前に追加された"files"タブだった
活発に進化していることで知られるJavaScript言語が、逆説的にも時代遅れの配布モデルに足を引っ張られているように見える

JavaScriptモジュールシステムの問題点

Nodeが作られた当時、JavaScript用の標準モジュールシステムは存在しなかったため、npmレジストリとNodeは根本的な欠陥があるCommonJS(require)システムを標準として採用した
- これはブラウザでは動作しないシステムだった
今からほぼ10年前の2015年に、言語自体がESモジュール(import)構文を採用した
今日では、ほとんどのJavaScriptはESモジュールを使って書かれているが、これらのモジュールを配布する方法は依然として複雑である
- 特にTypeScriptが関わる場合はなおさらである
このエコシステムにおける明白なギャップから、JSRが生まれた
- JSRは別のパッケージマネージャーではなく、サーバーサイドランタイム、ブラウザ、さまざまなツール間でJavaScriptとTypeScriptを共有する方法を刷新するために設計された、変革的なレジストリである

JSRの特徴と利点

JSRは、長年開発者を悩ませてきた複雑さを簡素化することで、コード配布プロセスを根本から改善する
ESM専用でTypeScriptファーストなJSRは、package.json設定や迷路のようなtsconfigコンパイラオプションの煩雑な調整を不要にする
パッケージスコアリングシステムを通じて、JSRはコード配布のベストプラクティスを促進する
- Dartコミュニティのpub.devと同様に、エクスポートされる各シンボルについて包括的なJSDocドキュメントを含むパッケージに、より高いスコアを与える
GoやRustのような他の現代的なプログラミングエコシステムで見られるように、JSRはデフォルトで自動ドキュメント生成機能を提供する

npmとの関係

JSRはレジストリであり、npmレジストリ向けの別のクライアントではない
- ただし、これはnpmのすべてを捨てたり、分離されたJavaScriptモジュールエコシステムへ移行したりしなければならないという意味ではない
JSRはnpmレジストリを補完するよう設計されており、npmを置き換えることを目的としていない
- JSRパッケージはnpmパッケージに依存できる（例: このパッケージ参照）
また、JSRパッケージは既存のnpm中心のソフトウェアでも利用できる
- JSR自体がnpm互換のtarballを配布するnpmレジストリ（npm.jsr.ioでアクセス可能）として動作するため
- これにより、JSRパッケージをnpm、yarn、またはpnpmを使うあらゆるソフトウェアに組み込み、プライベートレジストリと統合できる
JSRが配布するnpm tarballは最適化されている

セキュリティ重視

Denoでは、JavaScript開発においてセキュリティを最優先課題としている
どのレジストリも公開されたすべてのコードを包括的に監視することはできないが、JSRは発行者に関する透明性を提供し、発行プロセスを保護する
GitHub ActionsとOIDCトークンを統合することで、JSRはソフトウェアアーティファクトのためのSupply-chain Levelsを利用して、高度で検証可能な来歴証明を生成し、それをSigstoreに保存する
- これはコードの真正性を保証するだけでなく、開発者が実装する内容に対する信頼と責任を確立する

JavaScript開発の中心地

JavaScriptは、多くのプログラマーにとって共通言語であり、普遍的でアクセスしやすい
この言語には、開発者が不要な複雑さなしに成果物を共有できる中央ハブ、いわばタウンスクエアが必要である
私たちは、JavaScriptが今後長年にわたってソフトウェア開発の中心であり続けると信じており、JSRはその継続的な重要性を支えることを目指している
JSRは単なるエコシステム内の別のツールではなく、JavaScriptとTypeScriptの配布について私たちが考える方法の根本的な変化を示している

3件のコメント

yangeok 2024-04-30

jsrはnpmからダウンロードできた気がするんだけど、、（笑）

zzzz2222 2024-04-26

くたばれ php

semjei 2024-04-29

JSの記事でどうしてPHPを??
PHPのプロジェクトをやっている立場として、胸が痛みます。