Simplify Package Releases – From Versioning to Publishing

So, we've got seven minutes. I didn't even prep slides. Now, I could show you how we go from a 10x developer to an Nx developer, but we don't have enough time. My name is Juri. I'm a core team member of Nx. There is a lot of stuff we do from local development to CI, so we have a lot of support.

What I want to focus on is the Nx release command that we pushed out half a year ago roughly to the public, and it's basically about publishing npm packages. I have here a local npm workspace, so if I go to the package JSON, you can see here there is an Nx version installed, there is an npm workspace set up in a package in examples, and if I actually run an Nx graph, which you can run in any workspace even if you don't have Nx installed, it will show you how the structure looks like. It is inspired by 10-sec query which uses Nx to develop their packages. I hope Dominic doesn't watch because there is no logic behind here.

I want to show what it means to version, generate change logs and publish these types of packages. There are solutions out there, but usually, they lack a bit when it comes to a monorepo set-up. You have some dependencies there, especially if we talk about versioning, but even in the publishing process, if we push out these packages to npm, we don't want to push out a package that we want to push out in the right order because we don't want to have a package end up there, your network goes down in the middle, and you end up with a dependency that is not outpublished yet. How does it work? Basically, you can run a single command which is an Nx release. This is our first release because we don't have one yet. Then you run minus D which is a simulation mode. I want to do a dry run to see what happens. It goes through the package that you have. Yes, we want to release a major version. As you can see, it prints out a diff of what would happen, so it increments the version accordingly. It also updates local dependencies that you might have in that workspace, and it generates a change log if it needs to be generated. Basically, I can go and drop that minus D. Run again the major version, and go ahead and create that. The first step down here, it asks for publishing. I don't want to push that out on npm, but what we can do here is I have set up a local Verdasho npm registry. You can do that. We have a generator that helps you set that up. If you run Nx set up Verdasho, it would create that for you, and now we can run something like local registry. Typing with this inclination is pretty interesting. This would be our local Verdasho.

I removed that immediately, so it's pretty bright. This runs now and rewrites all my local publishing, so I can hit through and it would then deploy this to this local Verdasho instance. In fact, if I go back, you can see the actual packages pop up there.

In the real-world scenario, you don't want to go and every time manually specify what version you want to increment, whether it's a major or not, so there's the possibility in the NxJSON here to configure some of that. Now, if you run NxRelease again, just run it through, it automatically detects this is a minor update we make, so the version you want to get is 1.1.0, and we can say we want to publish this, and we also get here now a change lock at the root that is in this representation. Now, there are some more options that you can configure there. You can define what is the actual product relation in here, so is it like something that you want to fix versioning so all the packages are incremented at the same time, you want to have independent versioning, and also things like you want to have GitHub releases at the same time being pushed rather than just npm. You can do more stuff in the sense of having group releases which is pretty interesting, so in the sense that, in this case, for instance, we have, if you look, more React-related parts, we have a solid in here, and more core parts, so you could even go ahead and say you want to have some sort of release groups.

These are some of the features that we implemented in that Nx release version. It is right now one of the packs that we support is like JavaScript, but you can extend it on your own. The general versioning and publishing process. We even have one for Rust, and it can be extended to other languages as well. There's a lot of the features and stuff that I showed you today is like on our docs, so there's like a managed releases in general which has a walk-through video, and as well down here, you see a bunch of different recipes for customising and automating releases on your CI system, how to do NPM provenance support, and those types of things you would want to have in an open-source packaging publishing way. All right, that's it. That's all I can show you so far. We're still outside of the booth, so if you want to check that out and come by and dive a bit deeper, happy to answer questions. Thank you.