Using custom tags like beta to call npm packages is a shot in the dark—what do these names even tell you? They’re vague and could point to unstable or entirely different packages. These packages can easily slip into your CI/CD pipeline, installed by an unassuming developer, breaking your production builds.

Custom tags lack consistency. Any developer can change what they point to, making them hard to trust, especially stable labels. You need a clear, standardized naming convention, like SemVer2 and its handy Pre-release Labels, to make sure only your stable packages hit production.

In this article, I’ll look at why you might already be using npm custom tags—and why it’s better not to. You’ll learn how SemVer2’s Pre-release Labels are a better alternative and how to label npm packages consistently and reliably, in line with widely adopted practices.

Why use Custom Tags and Why they’re Problematic?

You’re probably using custom tags like alpha and beta to indicate a package’s stage of development. You likely call the latest tag too—but in practice, it’s the only custom tag you should use, really helpful for quick setups when installing the latest release is needed.

This is because using custom tags might feel intuitive, but can leave other developers wading through a swamp of package identification issues:

💥 One developer’s idea of an informative label, like crista’s_beta, is likely meaningless to the rest of the team.

💥 Custom tags are mutable, with pointers reassigned to different packages leading to installs of unrelated and unstable builds.

💥 Never mind reassigned packages, how do you know the tag pointed to the right package to begin with?

So, custom tags are unreliable, can point anywhere, and offer no useful information. Without consistent, immutable naming conventions, you risk installing crummy packages that will circulate through your CI/CD pipeline, breaking your applications.

Establishing a standard, consistent set of names your team can stick to is key to quelling package uncertainty in your CI/CD environment, and can be done with Pre-release Labels.

Why using Pre-release Labels is Better

Semantic Versioning 2 (SemVer2) uses Pre-release Labels as straightforward, no-change-allowed tags to keep package names consistent, like 1.1.5-alpha.3, which shows it’s the third alpha version. Labels like alpha (early builds), beta (later testing), and rc (almost ready) make things way cleaner than random custom tags for a few key reasons:

💡 Immutability means Pre-release Labels cannot be changed or reassigned, so you know exactly what package you’re looking at.

💡 Pre-release Labels aren’t pointers, so unlike custom tags they can’t be used to install mystery packages.

💡 They can only be used for unstable package versions, so there’s no way a developer can mistake them for a final build.

Choosing a set of standardized, purposeful Pre-release Labels tailored to your project lets you signal instability and prevent reassigned package names, so your team can stay on the level when handling packages—and unstable packages won’t be sneaking into your CI/CD pipeline.

Best Practices for Managing your npm Packages

Custom tags seem intuitive—after all, how could you forget what a tag you created means? In reality, other developers struggle to decode their meaning and question package stability. Wrong assignments, reassignments, and easy installs of unfinished code propel unstable packages to production.

Pre-release Labels are a clear, purposeful, immutable naming standard, removing the uncertainty around a package’s use and stability. These are the solution to your team’s naming issues, eliminating the risk of mystery package names resulting in broken builds.

Whoa, we covered a lot today! If you’re thinking of using Pre-release Labels, I suggest favoriting this page for reference! Even better, it’s packaged in our guide, Mastering npm in the Enterprise. It’s loaded with info on handling npm package dependencies, scoping, managing vulnerabilities, license compliance, and more. Sign up for your free copy today!