Don’t upgrade your npm package versions by accident

Looking for ways to make sure that your deployments to different environments are identical and use the exact same package versions? Or does your company have requirements to be able to reproduce deployments and trace exactly what dependencies were used at a specific time? Great - continue reading!

Being dependent on open source 📦 npm packages means dependencies to the public npm registry and npm package maintainers = constantly changing environment. This also means that you have the responsibility to keep track of what package versions were used in a specific deployment. This is a crucial task to reduce risks and make sure unintended changes have not been made.

Even without any change to package.json your builds may produce a different set of dependencies at different points in time (semver versioning and addition of new minor versions to public registries).

The slightest change in patch versions means your builds are no longer deterministic where you are guaranteed the exact same results - and deploying dependencies that have not been tested is never a good idea...

So what's the solution?

💡 For me, the way to go is to freeze your registry when you want to avoid accidental updates. Freezing a registry effectively locks down the state of your package versions and makes the registry read-only so that only intended changes are applied to code you trust.

The video below shows the easiest way to make your registry read-only using the Freeze policy in Bytesafe:

Benefits of using the Freeze policy in Bytesafe:

✅ Guaranteed exact same versions when testing and building your applications

✅ Deterministic and consistent results across all your environments such as Test, UAT and Production

🔗 This blog post also describes how to work with the Freeze policy to achieve consistent tests and builds.

What's your solution to this issue?

I would love to hear what you think of this solution and how you avoid accidental updates today. I'd be happy to answer any questions you might have.

22