JSRが！公開された！
最近、JSRというワードが話題になっています。
JSRは、JavaScript Registryの略で、次世代JavaScript/TypeScriptのパッケージレジストリらしいです。
npmと何が違う？
npmは、Node Package Managerの略で、その名の通り、Node.js用に開発されたパッケージマネージャー、また、そのパッケージマネージャが使うレジストリです。
その利便性から、Node.js以外の、ブラウザーやほかのランタイムでも用いられています。
例えばsvelteはブラウザ用のパッケージですが、Node.jsのパッケージマネージャーnpmのレジストリに登録されています。
Node.jsのために作られことから、以下のような欠点があります。
- TypeScript非対応
- TypeScriptファイルをそのままpublishしたり、ビルドしてpublishすることはできますが、スマートではありません。
- ESMに追いついていない場合がある
- CJSのパッケージはたくさんあります
一方、JSRは以下のような特徴があります。
- ピュアなTypeScriptサポート
- TypeScriptをそのままpublishできるっぽいです
- Node.jsなど用に
.d.tsも自動で作成してくれます
- ESM
- ESMパッケージしか公開できないので、モダンです。
また、決定的な違いとして、役割の違いがあげられます。
npmはパッケージマネージャ/レジストリです。一方JSRはレジストリです。パッケージマネージャの役割を持っていません。
例えば、Node.jsでパッケージ@std/assertをインストールしたいとき、以下のようなコマンドを用います。
npx jsr add @std/assert
「なんだ、パッケージマネージャじゃん」って思ったかもしれません。しかし、このコマンドはパッケージマネージャではありません。
理解するために、手順を見てみます。
まず、コマンド実行で、package.jsonが、以下のようになります。
"dependencies": {
"@std/assert": "npm:@jsr/std__assert"
}
次に、npmなら.npmrc、Bunならbunfig.tomlなどに@jsr:をhttps://npm.jsr.ioに解決するコードを追加します。
最後に、npm iで依存関係をインストールして完成のようです。
jsrコマンドは、npmを用いるときにいい感じにjsrを使えるようにしてくれるラッパーなのです。パッケージマネージャーではありません。
ちなみに、https://npm.jsr.ioはJSRパッケージをnpm用に変換して配信するサーバーのようです。
Denoのために作られた
JSRは、Denoのために作られたらしいです。
次世代https://deno.land/x/*的な立ち位置です。
そのため、DenoにもJSR用のさまざまな機能が搭載されています。
jsr: import
import * as package from 'jsr:@xxx/xxx@version'
のようにしてJSRパッケージをダウンロードして使えます。
deno add *
上のものだと、deno.land/xなどのようにバージョン管理が難しいです。
// deno.json
{
"imports": {
"@std/assert": "jsr:@std/assert@^0.218.2"
}
}
このように、importMapを使ってdeno.land/xのようにできます。
これを簡略化するのがdeno addで、
deno add @std/assert
でいけちゃいます。
deno publish
deno.jsonに
{
"name": "@scope/package",
"version": "1.0.0",
"exports": "./mod.ts"
}
でdeno publishでいいんです！簡単！
JSRに公開できちゃう！
その他の機能
- JSDOCから自動でドキュメント生成
- パッケージスコアリング
- すごいコンパクトなGitHub Actionsからの自動publish
最後に
JSR、めっちゃやばそうです。
分散型じゃないのがちょっとなーって思いました。
何かpublishしてみたいです
参考
リンク
Discussion