Making external links safe — JAMStack style

Update on moving from JavaScript to markdown processing for safe external links, and my experience publishing a modified package on npm.

An itch to do better

I had previously shared a JavaScript snippet for improving the security of external links on my blog.

Since then, I have moved over to Eleventy and have been working on bits and pieces of my site whenever I can. One of the things that started bothering me lately was the fact that this snippet relies on JavaScript being enabled in the browser of the visitor.

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.

Additionally, why use extra JavaScript when it can in fact be done while generating the site? That’s the whole point on JAMStack after all!

For the unaware, external links on my site carry an arrow next to them, like so:

An link with an arrow next to it, indicating itself as an external link

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 head tag. 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.5 release 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 eslint binary, 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[1] and published my version of the package on npm. [2] 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. [3][4]

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.

Footnotes

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.

0

Comment via email.