How I Built and Published My First Angular Library

I’ve always been curious about how writing code for a library differs from writing code for regular application. How is it different from writing normal application code. Is the setup more complicated, because you need to transpile to different versions? Is it vastly different between a frontend (React, Angular, etc.) library versus a NodeJS library?

You hear a lot of things about libraries being much more complex, especially the type gymnastics.
I am pleasantly surprised to discover that, at least for a simple project, it wasn’t as different as I feared. It was actually surprisingly easy, for my limited application.

So how does one actually build and publish an angular library? Let’s dive in!

So what are we building?

I have a been a longtime user of the changelog service Headway, and built a simple angular implementation in the Introdus codebase, while I was still employed there.
I thought, since I had effectively built in an API integration at the application level, without an SDK, maybe it wouldn’t be a bad idea to create one layer of abstraction (as we know, all software problems can be solved with another layer of abstraction, except the problem of too many abstractions 🤷‍♂️) on top.

So that’s what I decided to do: extract (and abstract) the implementation of Headway, into a library of its own, that would have a simple implementation, ideally as simple as an Angular Directive.

First things first: Setup a codebase where we can build and test it

I was debating whether to go for a setup with nx – a monorepo tool I’ve been meaning to try for a long time – or a simpler setup. I started out with nx, spent several hours with it, trying to get the environment set up just quite right but ultimately threw in the towel and decided to go a simpler route.

It seems like overall nx is a great tool, but it was too frustrating having to learn “simple” things over again, in order to do things with nx. So I decided to call it quits for now.


So instead, I simply started by setting up a brand new Angular project using the ng CLI, making sure I had the most recent version installed. Angular also has some excellent documentation on creating libraries, which guided me through some of the confusing parts of the configuration (how does one compile a library, or include it within a regular application?).

To follow best practices, I wanted an isolated folder for managing this (and other potential future libraries), so I created a new root folder projects and initialized my library within it. This setup required some modifications to angular.json as explained by Angulars documentation.

Running yarn run dev from here let me see the expected Angular demo page, and that’s really all I needed for this simple project.

Building the Library

It took a solid evening hour of work, but I managed to solve it relatively quickly – again, this is a very simple project.
My new library “ngx-headway” (which you can check out here) ended up shipping a simple directive, that can be introduced onto any element in order to render a “grey dot”.

image of 'whats new' with a gray dot

Its a familiar indicator that turns red when there are unread news on the changelog.

I choose to keep the API straightforward to make it easy to use. The directive headwayBadge can be added to any element, and the component handles the rendering of the notification indicator.

To use the library, a developer simply needs to:

  1. Provide a HEADWAY_ACCOUNT_TOKEN in their providers.
  2. Use the headwayBadge directive on any element where they want the indicator to appear.

The value that must be supplied for this provider token, is an api key, that developers can acquire from setting up an account at Headway.

I believe this approach keeps the implementation minimalistic and clean which means its easier to use for developers. If I intend for others to use this I need to make it as friction less as possible to adopt it.

Publishing the Library

Before publishing, I had to update a few properties in package.json that I hadn’t considered before, such as:

  • repository (so users can find the source code)
  • keywords (to improve discoverability on npmjs.com)
  • author (to credit myself as the creator 🤷‍♂️)
  • license (to specify usage rights)

Going from here to published library not only seemed a little daunting and confusing, but frankly also a bit intimidating.
“Who am I to publish a library?”

I think we can all relate to that feeling of imposter syndrome, something I’ll admit is becoming more and more rare. I had to remind myself (a few times) that, even if nobody downloads this, I’m doing it to learn.

First things first, I actually need a user on npmjs.com, and have 2FA setup in order to publish a library there. Without 2FA you simply can’t publish. I think that’s pretty solid, so super cool that they’re enforcing that.

With everything in place, I was able to build the package using Angular’s built-in tooling and published it to npm. The whole process turned out to be smoother than I had anticipated.

That’s it!

It feels a bit surreal, but super cool to have a library publish on the most popular platform for Javascript libraries 😄

Lessons Learned

Let’s sum up what I actually learned from this little fun experiment:

  • Writing library code isn’t at all that different from writing application code! At least not for simple use cases like this one.
  • Setting up the library and making it testable has a few quirks (changes to angular.json, letting angular know about it etc.), but the angular docs helps a ton.
  • Having an application to test your library in is essential to making sure things work, and ensuring you understand how developers will be interacting with your library.
  • Npmjs.com actually requires 2FA in order to be able to publish libraries.
  • AI is surprisingly bad at helping with this process

So that’s my little experiment trying to release an Angular library (that you are free to download and use right now!). It was fun, and although not the longest learning experiment in the world, one I had been eying for a while, so it was awesome to finally get around to it.

Do you want the cheat sheet for easily going from scratch to building your own Angular library?
Sign up for my newsletter, and I’ll send it right to your inbox, as soon as its ready! 👇