An itch to do better
What if they have turned it off? True – they wouldn’t then be susceptible to the kind of attack that the snippet aims to protect you against. However, such visitors also lose access to the context that other readers have: that this link is external and opens in a new tab.
For the unaware, external links on my site carry an arrow next to them, like so:
Moving to JAMStack style content processing
I searched for Eleventy plugins on npm, and found eleventy-plugin-safe-external-links by snugug.
However, upon using it…
- I found out it ravages my site’s
headtag. This is due to an underlying issue with cheerio. This fix should already have been in a release but wasn’t.
- It wasn’t quite feature-complete for my needs. I also wanted external links to open in a new tab.
- npm also currently shows a
v0.1.5release but the package.json file on the repo still specifies
v0.1.4. Unfortunately, no changelog either!
- Even the tests wouldn’t run for some reason. It probably couldn’t find all the required dependencies and did not look up the tree for an
eslintbinary, for example. Frankly, I can’t remember what it was, other than the feeling of general frustration with all the issues combined.
- I was unsure if all the changes I wanted to make would be accepted by the project author/maintainer. He is quite responsive and open to PRs but it just seems easier to drive my own project as per my specific needs and keep it open source for others’ benefit.
The module is great, but needs better maintenance.
Publishing my own version on npm
So, I forked the project, stripped it down to a micro-repo and published my version of the package on npm.  It has bunch of small differences compared to the original repository, which are listed in the README to comply with the Apache 2.0 license. I’m using Keep A Changelog’s template on my annotated git tags. 
Publishing the package was quite easy, thanks to npm’s documentation, and probably took a total of five minutes. Amazing!
I hope others also find it easier to contribute, raise issues, and watch for any progress. This is definitely one of those scenarios where I like the idea of do-one-thing-but-do-it-well.
Would that be the opposite of a monorepo?
Read more about user/organisation scoped packages. Ideally, always aim to publish scoped packages.
Not sure what tagging is? Take a look at Git Basics – Tagging.
I also learnt that releases is a feature limited to GitHub. So far, I was under the impression that annotated tags automatically get published as a release, or that one could release a package using git’s CLI itself. This does not appear to be true.