Shipping my first npm library

At Microsoft, my team is responsible for building the tools that help manage and maintain the company's enterprise network. Our team has about 10 developers and almost as many active products.

The Problem

Historically, this team did not have many UI engineers. Most applications weren't even created by members of the team as it stands now. Some of the projects were created using a smattering of vanilla JavaScript, Angular, and only recently: React.

Each application integrates with Azure tools like Azure Active Directory and Application Insights in different ways, and none of them follow any consistent design or style. Since the tools were initially considered purely internal, they weren't given much love in terms of accessibility or experience.

Another big issue is that every project has disparate design patterns and isn't guaranteed to have the proper CI/CD pipelines in place. This makes it very difficult for engineers to on board and develop for those projects.

The Solution

In order to provide consistent look and feel to our customers, we decided to adopt the Microsoft Coherence design system. The folks in the Core Services Engineering & Operations (CSEO) studio provided us with a component library that has Microsoft's look and feel out of the box.

With the component library in place, I wanted to build a library of tools that can be used across all of our projects to make things like logging and authentication a breeze to setup. That's where the Core Engineering Shell comes in.

Core Engineering Shell

The very first thing we put into the CEShell (pronounced SEA-SHELL) library is some wrappers around the Azure Application Insights library. The library itself is complete and comprehensive but I wanted to abstract some of implementation.

For example:

appInsights.trackTrace({SeverityLevel.Info, "This is an info level log"});
appInsights.trackException({exception: "This is an exception"});

becomes

logger.info("This is an info level log");
logger.exception("This is an exception");

It's a small abstraction, but it's so much easier to read and will help the code base look more clean. We've implemented this for all of the Azure Application Insights severity levels as well as for the exceptions.

One of the benefits of this is that if Azure Application Insights ever introduces breaking changes, we can just change their implementation in CEShell rather than having to manually make changes everywhere we used the broken functionality.

Learning Curve & Struggles

The biggest part of the learning curve for me was getting used to using npm link to do local development and learning more about the build and release tools in Azure DevOps. We ran into a bit of bureaucratic challenges with permissions on the internal npm registries, but as far as technical challenges it was mostly about how to setup local development.  

Future Work

The next feature we will be implementing is the integrations for Azure Active Directory which is how we authenticate all of our applications.

Again, one of the benefits here is that if we abstract the library implementations out of each application; we can swap out our authentication providers (adal, msal, etc.) without much rework in the client applications.

Another piece will be providing some common layouts and components that we will reuse across all of our applications to ensure common patterns and consistent experiences.