markuplintを開発し始めて5年経った

2022/10/10に公開約7,500字

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を何卒くよろしくお願いします。

GitHubで編集を提案

Discussion

ログインするとコメントできます