DenoでHTMLタグを楽に書けるモジュールを作ってレジストリに公開した感想
本記事の主題はDenoの自作モジュールの説明ではなく、Denoのモジュール公開に関する所感について述べるものです。したがってIdea記事です。
markup-tagをリリースした
先日、markup-tagというモジュールをリリースしました。
機能
プログラム内でHTMLのソースを記述したいときに、
const div = `<div id="foo" class="bar">Hello world!</div>`;
ではなく
import { tag as h } from "https://deno.land/x/markup_tag/mod.ts";
const div = h("div", { id: "foo", class: "bar" }, "Hello world!");
のように書けるようになります。
また、<meta>や<input>などは閉じタグを作らないようにしています。
記事名ではわかりやすさのために「HTMLタグを楽に書けるモジュール」としていますが、タグ名として受け取る文字列は特に限定していないため、自分で定義したコンポーネントでもSVGのタグでも使えます[1]。
公開手順
公開手順は既にわかりやすい記事が存在しているので、本記事で再掲することは控えます。
deno.land/x についてはこちら：
nest.land についてはこちら：
これらの記事を見れば公開は問題なくできると思います。
また、自分の具体的な作業記録も画像つきで残していますのでご参考にどうぞ。
所感
deno.land/xについて
公開は簡単
deno.land/xは、GitHubでReleaseしたときのWebHook経由でレジストリに連携します。
このため、GitHubにないモジュールは公開できませんが、一度設定してしまえばあとはリリースを作るだけなので簡単です。
なぜかモジュール名にハイフンを使えない
アンダースコアは使えます。
GitHubのリポジトリ名と同じにする必要はないので、適宜変更すれば登録は可能です。
というかGitHubとの連携が必須なら、ユーザー名とリポジトリ名をそのままモジュール名に反映させても良かったのでは…。
細かい設定ができない
前述の「Release時にWebHookで公開する」以外の方法がないので、ローカルからpublishするとか、リリースを作った後にちょっとだけ修正したいとかはできません。
また、モジュールとして不要なファイル（.gitignoreとか）もページ上に公開されてしまいます。.denolandignoreみたいなことはできないようです。
不要なファイルに関しては、サブディレクトリにモジュールとREADMEの本体を配置し、そのディレクトリのみを公開すれば良いかもしれません。そこまでする必要があるか？というと疑問ですが。
nest.landについて
公開は簡単
eggsコマンドをインストールする必要があるものの、操作自体は別に難しくありません。
また、GitHub Actionsで設定を行えば、リリースを作ったタイミングでeggs publishを動かすことができるので、deno.land/xへの公開と同時に実行することができます。
バージョンナンバーを省略したインポートはできない
試してみましたができないようでした。
Download https://x.nest.land/markup-tag/mod.ts
error: Import 'https://x.nest.land/markup-tag/mod.ts' failed: 404 Not Found
両方について
バージョンナンバーの修正が大変
今回公開したモジュールですが、これを更新する際には
-
README.mdのサンプルに書いてあるバージョン -
eggs.ymlに定義しているバージョン
を修正しないといけません。これを忘れてリリースしてしまうと、READMEだけ更新されていなかったり、deno.land/xとnest.landでバージョンがずれたりします。
コード中でバージョンナンバーを扱っている場合、更に修正箇所が増えるでしょう。
公開したモジュールをあとから修正することはできないので、再度リリースする必要があります。
あと、deno.land/xに公開されているモジュールのバージョンはv1.2.3のようにvがついているものが多い印象ですが、nest.landでは1.2.3のようにvがないものが多いようです。
そういえばdenoとdeno_stdでも統一されていないし。
自分はvなしのほうに統一しました。
というかなぜ2つもあるの…？
deno.land/xのほうは1 user/organizationでの公開数制限があるので、それを考慮するとnest.landをメインに使うべきかもしれません。でも15個だからそんなにすぐ使い切るものでもなさそうです。
そもそもDenoのシステム上、GitHubなどで公開されていれば直接インポート可能なんですよね。
import { tag } from "https://raw.githubusercontent.com/kawarimidoll/deno-markup-tag/0.1.2/mod.ts";
そうするとなぜレジストリが存在しているのか…。
検索性とパスの長さの問題でGitHubから直接取り込むことはあまりないのですが。
おわりに
ということで、公開はできるけどちょっと直感と合わないところがあるかもな、という印象でした。
このあたりは自分がDenoエコシステムにまだ慣れていないためでもあると思うので、どんどん使って染まっていきたいと思います。
しかし、バージョンナンバーの修正は結構面倒だと感じました。
現状、リリースを作成したところから公開まではWebHook及びGitHub Actionsで自動化できているので、ここに更に処理を挟んで、以下のように自動化したいと思っています。
-
git tagでタグを発行、push -
tagの更新を検知してREADME.md、eggs.yml、その他コード内のバージョンナンバーを更新 - 更新されたバージョンを使ってReleaseを作成
- モジュール自動公開
既に自動化している方や、よりよい方法をご存じの方はコメントいただけると嬉しいです。
-
というかそもそもSVGを記述したくて作ったのでした ↩︎
Discussion