markuplintを開発し始めて5年経った
ESLintやTypeScriptを利用した開発の体験性をマークアップにも持ち込みたい、という思いから作り始めたmarkuplintもファーストコミットから5年が経った。長いような短いような。何かあるわけではないが、節目として折角だから備忘録としてこの5年間がどうあったかをしたためておく。
5年間の主な出来事
| 日付 | 出来事 | 補足 |
|---|---|---|
| 2017年9月26日 | 最初のコミット | |
| 2017年11月29日 | 最初のバージョンv0.1.0リリース |
|
| 2017年12月13日 | VS Code拡張をリリース | |
| 2018年1月19日 | ライトニングトークコードレビュー なんてしてられるかッ!!で公で初めてmarkuplintのことを話す。スライドは約11,000ビュー。はてブで312ユーザーがブックマーク。 |
v0.16.0時点 |
| 2019年2月1日 |
v1.0.0-alphaプレリリース |
パッケージを分割しモノレポ（Lerna）を採用 |
| 2020年10月1日 |
v1.0.0リリース |
|
| 2021年5月5日 | JSX（React）サポート |
v1.7.0時点 |
| 2021年11月15日 |
v2.0.0-alphaプレリリース |
|
| 2022年2月10日 |
v2.0.0リリース |
|
| 2022年6月28日 |
v3.0.0-alphaプレリリース |
devブランチで開発継続中 |
現在の数字
- 最新バージョン:
v2.10.1 - コミット数: 2,122
- IssueとPull Request: 530件（クローズ含む）
- npmダウンロード: 11,179（週間）
- テストコード数: 916
- テストカバレッジ: 74%
- GitHubスター: 315ユーザー
- スポンサー: 1ユーザー
ふりかえり
ライトニングトークでのお披露目
最初のコミットから約4ヶ月後、VS Code拡張も用意できて業務でもドッグフーディングしてある程度機能するようなったので、開発の動機と楽しんで開発できている旨をライトニングトークした。SNSを中心にそこそこ広まってくれたのもあって、GitHubのスターが増えたり、「使ってみよう」という声をぼちぼちと聞くようになった。最初のアピールとしては良い滑り出しだったとは思う。
当然ながらスライドは日本語だしSNSの広がりも国内にとどまったので、GitHubのスターは未だに日本のユーザーが多い。しかし、嬉しいことにどこから知ったのかはわからないが、ぼちぼちと国外のユーザーもスターを付けてくれたり、IssueやPRを作ってくれたりし始めた。英語でのコミュニケーションは大変だが、それよりも嬉しさが上回るので感謝しかない。ただもっとユーザーは増えて欲しいので英語圏へのアピールは今後も大きい課題になっている。dev.toとかに記事を書くのがいいのかなぁ…。一番いいのは然るべきカンファレンスで話すことだろうけども…。
v1.0.0リリースに随分と時間をかけた
改めて出来事を見返すとv1.0.0-alphaからv1.0.0までに1年半かけている。今思うと慎重過ぎたかもしれない。APIのBreaking Changesを避けたいばかりに調整を繰り返したり、機能やルールを欲張ったのでこれだけ時間がかかっている。この間、具体的な数字はわからないが、利用数が伸び悩んだような印象がある。まあ水面下でしか開発が行われていない状況は外から見たら開発が止まっているように見える。OSSを採用するポイントとして「プロジェクトが生きているか」は大事な要素だと自分も思うので、このあたりはちょっと反省できるところだったように思う。
結局対応したJSXのサポート
当初、JSXはTypeScriptがあれば（もしくはきちんと進化すれば）不正な属性（JSX的にはプロパティ）の問題はそれには不要だと考えていた。しかし、いざ自分がReactのプロジェクトに多く触れるにつれて「やっぱりJSXもサポートできたほうが絶対いいよなぁ」と考えるようになった。最終的に同じHTML（もしくはDOM）を提供するのに、HTMLやVueでは得られる体験をReactでも体験できないのはなかなかのストレスだったので、作ることにした。属性（プロパティ）の型チェックは望みがあったし部分的に解決できていたが、構造のルール（Permitted Contents）の違反が、どのプロジェクトを見ても圧倒的に多かったことが理由として大きく、またその部分はおそらくTypeScriptでは解決しにくいとだんだんわかってきたからだった。
ちなみにJSXをサポートしたからといって構造のルール違反をすべて解決できたわけではない。ネイティブのHTML要素の構造はチェックできるようになったが、JSXElementとしてコンポーネントにしてしまうと構造関係を検査できなくなる。しかし、次のメジャーバージョンv3.0.0ではそれを解決するためのpretenders機能を搭載したので、完璧ではないが徐々に解決に向かいつつある。
メジャーバージョンのスピードを早くする
v0からv1への遅さは反省点だったが、とは言ってもv1.0.0でのこだわりが有効に働いてメインのmarkuplintパッケージのBreaking Changesは最小限に留められた状態でv2.0.0をリリースできた。コンフィグレーションファイルもコマンドもv1のままv2でも動く。死守すべきはこのコンフィグレーションとコマンドの互換性ということがなんとなくわかってきた。
壊していいところと壊す場合に慎重になったほうがいいところが掴めてきたので、まずは臆せずなるべく早く「やりたいことはやってしまう」ことにした。その考えができたおかげでv3への開発はわりと早めに取り掛かれていて、現在はプレリリース中だが、年内にもリリースできる予定だ。内部的なAPIは結構変化があるが、今回もコンフィグレーションとコマンドの互換性は保てている。
ただ、次のv4に向けてはESM対応が待っているので、どうするか結構悩んでいる。本当はv3でESM対応するつもりだったが未だしっかりと理解できていなかったり環境を整える時間がとれなかったため見送っている。もしかしたらv4でも見送るかも…。
これからの話
改めてふりかえると良くも悪くも個人開発だったなあと思う。リポジトリはOrganizationにしているが、完全にひとりでやっている。誰か一緒にやってくれる人が増えてくれたらと常々思いつつも（たまにツイートもしてた）、かと言ってPdMできる自信やモチベーションが今のところ準備できていない。時間も作れる予定がない。誰かを無責任に巻き込むよりも細々とやるのでいいのではと最近は思っている。PdMをやって引き継ぎたいって人いないかしら…。
Forkされたり真似されて別のツールに取って代わられるのも構わない。HTMLHintにもちょっと期待していたけど、あっちはあっちで独自の路線を行っているっぽいので同じ機能が搭載されることはなさそう。あとは期待はRomeだろうか。Romeがしっかり進化してデファクトになり、リンター部分のフックに都合の良いAPIがあれば、markuplintの機能を移植できるかもしれない。そうすればプラグインの開発だけで済むのに…。
「世の中のHTMLがちゃんと書かれること」 が叶えたいことなので、markuplintは僕にとっては手段であって目的ではない。ただし、今のところ役に立てているプロダクトもいくつかあるので開発は辞めるつもりはない。もっとよいツールが現れるまで、がんばってみようと思う。
応援方法
最後にこんな個人開発ツールですが、応援したいと思っていただける方に応援方法を紹介しておきます。
上記のいずれかを少しでもやっていただけると、とても、いや、かなり励みになります。
これからもmarkuplintを何卒くよろしくお願いします。
Discussion