This is an old post. Information here may be out-dated, or the post may re­flect opin­ions or be­liefs I no longer share.

An itch to do bet­ter

I had pre­vi­ously shared a JavaScript snip­pet for im­prov­ing the se­cu­rity of ex­ter­nal links on my blog.

Since then, I have moved over to Eleventy and have been work­ing on bits and pieces of my site when­ever I can. One of the things that started both­er­ing me lately was the fact that this snip­pet re­lies on JavaScript be­ing en­abled in the browser of the vis­i­tor.

What if they have turned it off? True - they would­n’t then be sus­pectible to the kind of at­tack that the snip­pet aims to pro­tect you against. However, such vis­i­tors also lose ac­cess to the con­text that other read­ers have: that this link is ex­ter­nal and opens in a new tab.

Additionally, why use ex­tra JavaScript when it can in fact be done while gen­er­at­ing the site? That’s the whole point on JAMStack af­ter all!

For the un­aware, ex­ter­nal links on my site carry an ar­row next to them, like so:

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

Moving to JAMStack style con­tent pro­cess­ing

I searched for Eleventy plu­g­ins on npm, and found eleventy-plu­gin-safe-ex­ter­nal-links by snugug.

However, upon us­ing it…

  • I found out it rav­ages my site’s head tag. This is due to an un­der­ly­ing is­sue with chee­rio. This fix should al­ready have been in a re­lease but was­n’t.
  • It was­n’t quite fea­ture-com­plete for my needs. I also wanted ex­ter­nal links to open in a new tab.
  • npm also cur­rently shows a v0.1.5 re­lease but the pack­age.json file on the repo still spec­i­fies v0.1.4. Unfortunately, no changelog ei­ther!
  • Even the tests would­n’t run for some rea­son. It prob­a­bly could­n’t find all the re­quired de­pen­den­cies and did not look up the tree for an eslint bi­nary, for ex­am­ple. Frankly, I can’t re­mem­ber what it was, other than the feel­ing of gen­eral frus­tra­tion with all the is­sues com­bined.
  • I was un­sure if all the changes I wanted to make would be ac­cepted by the pro­ject au­thor/​main­tainer. He is quite re­spon­sive and open to PRs but it just seems eas­ier to drive my own pro­ject as per my spe­cific needs and keep it open source for oth­ers’ ben­e­fit.

The mod­ule is great, but needs bet­ter main­te­nance.

Publishing my own ver­sion on npm

So, I forked the pro­ject, stripped it down to a mi­cro-repo[1] and pub­lished my ver­sion of the pack­age on npm. [2] It has bunch of small dif­fer­ences com­pared to the orig­i­nal repos­i­tory, which are listed in the README to com­ply with the Apache 2.0 li­cense. I’m us­ing Keep A Changelog’s tem­plate on my an­no­tated git tags. [3][4]

Publishing the pack­age was quite easy, thanks to npm’s doc­u­men­ta­tion, and prob­a­bly took a to­tal of five min­utes. Amazing!

I hope oth­ers also find it eas­ier to con­tribute, raise is­sues, and watch for any progress. This is def­i­nitely one of those sce­nar­ios where I like the idea of do-one-thing-but-do-it-well.


  1. Would that be the op­po­site of a monorepo? ↩︎

  2. Read more about user/​or­gan­i­sa­tion scoped pack­ages. Ideally, al­ways aim to pub­lish scoped pack­ages. ↩︎

  3. Not sure what tag­ging is? Take a look at Git Basics - Tagging. ↩︎

  4. I also learnt that re­leases is a fea­ture lim­ited to GitHub. So far, I was un­der the im­pres­sion that an­no­tated tags au­to­mat­i­cally get pub­lished as a re­lease, or that one could re­lease a pack­age us­ing git’s CLI it­self. This does not ap­pear to be true. ↩︎