Five Years Since I Started Developing markuplint

Five years have passed since the first commit of markuplint, which I started developing with the desire to bring the development experience of ESLint and TypeScript to markup. It feels both long and short. Although there's no specific occasion, I'd like to take this milestone as an opportunity to write down how these five years have been as a memorandum.

Main Events Over the Last 5 Years

Date	Event	Supplement
Sep 26, 2017	First commit
Nov 29, 2017	Released first version v0.1.0
Dec 13, 2017	Released VS Code extension
Jan 19, 2018	Spoke about markuplint in public for the first time at the lightning talk Code Review? I can't be bothered with that!!. The slides have about 11,000 views. Bookmarked by 312 users on Hatena Bookmark.	As of v0.16.0
Feb 1, 2019	v1.0.0-alpha pre-release	Split packages and adopted monorepo (Lerna)
Oct 1, 2020	v1.0.0 release
May 5, 2021	JSX (React) support	As of v1.7.0
Nov 15, 2021	v2.0.0-alpha pre-release
Feb 10, 2022	v2.0.0 release
Jun 28, 2022	v3.0.0-alpha pre-release	Development continuing in dev branch

Current Numbers

• Latest version: v2.10.1
• Number of commits: 2,122
• Issues and Pull Requests: 530 (including closed)
• npm downloads: 11,179 (weekly)
• Number of test codes: 916
• Test coverage: 74%
• GitHub stars: 315 users
• Sponsors: 1 user

Reflection

Unveiling at a Lightning Talk

About four months after the first commit, once the VS Code extension was ready and I had done enough dogfooding at work for it to be functional, I gave a lightning talk about my motivation for development and how much I was enjoying the process. Thanks in part to it spreading fairly well on social media, the number of GitHub stars increased, and I started hearing voices saying, "I'll give it a try." I think it was a good start as an initial push.

Naturally, the slides were in Japanese, and the social media reach was limited to Japan, so most GitHub stars are still from Japanese users. However, I'm happy to say that—though I'm not sure where they discovered it—users from outside Japan have gradually started starring the repository and creating issues and PRs. Communicating in English is challenging, but the joy outweighs the effort, so I'm incredibly grateful. However, I want to grow the user base further, so appealing to the English-speaking world remains a major challenge. Perhaps writing articles on dev.to would be good... although the best way would likely be speaking at an appropriate conference...

Spent a lot of time on the v1.0.0 release

Looking back at the timeline, it took a year and a half from v1.0.0-alpha to v1.0.0. In hindsight, I might have been too cautious. I spent so much time because I was constantly making adjustments to avoid breaking changes in the API and got greedy with adding features and rules. During this period, although I don't have specific numbers, I had the impression that the usage growth stalled. A situation where development only happens behind the scenes can look like it has stopped from the outside. I believe "whether a project is active" is a crucial factor when choosing an OSS, so I think this is something I can reflect on and improve.

The JSX Support I Ended Up Implementing

Initially, I thought that if TypeScript existed (or evolved properly), the issue of invalid attributes (properties in JSX terms) wouldn't need an extra tool. However, as I personally started working on more React projects, I began to think, "It would definitely be better if JSX could be supported too." It was quite stressful not being able to have the same experience in React as one does in HTML or Vue, despite ultimately providing the same HTML (or DOM), so I decided to build it. While there was hope for attribute (property) type checking and it was partially resolved, the main reason was that violations of structural rules (Permitted Contents) were overwhelmingly frequent in every project I saw, and I gradually realized that this part is likely difficult to solve with TypeScript.

By the way, supporting JSX doesn't mean all structural rule violations have been resolved. While native HTML element structures can now be checked, once they are converted into components as JSXElements, the structural relationships can no longer be inspected. However, in the next major version v3.0.0, I've included a pretenders feature to address this, so while it's not perfect, it's gradually moving toward a solution.

Increasing the Speed of Major Versions

The slowness from v0 to v1 was a point of reflection, but even so, because of the dedication in v1.0.0, I was able to release v2.0.0 with minimal breaking changes to the main markuplint package. Both configuration files and commands from v1 still work in v2. I've come to realize that the compatibility of these configurations and commands is what should be strictly protected.

Since I've grasped what can be broken and where I should be cautious when breaking things, I decided to first do "what I want to do" as quickly as possible without hesitation. Thanks to that mindset, development for v3 started relatively early; it is currently in pre-release and is scheduled for release by the end of the year. While there are significant changes to the internal API, compatibility for configurations and commands is maintained this time as well.

However, looking towards the next v4, ESM support is waiting, so I'm quite torn about what to do. I actually intended to support ESM in v3, but I skipped it because I didn't fully understand it yet or couldn't find the time to set up the environment. I might even skip it in v4 too...

Future Plans

Looking back, for better or worse, I feel that it has been a personal development project. The repository is set as an Organization, but I am doing it entirely alone. While I always wish more people would join me (I even tweet about it sometimes), I don't have the confidence or motivation to be a Product Manager (PdM) right now. I don't have any plans to make time for it either. Recently, I've started thinking that it's better to keep doing it quietly rather than involving someone irresponsibly. I wonder if there's anyone who wants to take on the PdM role and take over...

I don't mind if it's forked or imitated and replaced by another tool. I was hoping for something from HTMLHint, but it seems they are going their own way, so it's unlikely the same features will be implemented. Another hope is Rome. If Rome evolves properly and becomes the de facto standard, and if there's a convenient API for linter hooks, I might be able to port the functions of markuplint. Then I would only need to develop a plugin...

"Ensuring that HTML in the world is written correctly" is what I want to achieve, so markuplint is a means for me, not the goal. However, since there are some products it is helping right now, I have no intention of quitting development. I will keep doing my best until a better tool appears.

How to Support

Finally, even though it's a personal development tool, here are some ways you can support it if you feel like it.

• Use it
• Install the VS Code extension
• Report bugs in Issues
• Submit feature requests in Issues
• Create PRs
• Become a sponsor
• Tweet about it
• Write articles
• Introduce it to others

If you could do any of the above, even just a little, it would be very—no, quite—encouraging.

Thank you for your continued support for markuplint.