00:00 So far we just ran versioning and changelog generation, but we didn't actually publish our packages. Now the ultimate goal obviously is to publish these packages with the recording version and changelog to some public registry, most probably NPM, but if you are within an organization or company, you might even have a local registry running in your company that is a private one.

00:19 Now, if you want to test though our packages, it's actually pretty handy to run a local NPM registry to which we can publish the packages, see how it works and test out our releases as well. This can not just be interesting for local testing, but also for running end-to-end integration tests potentially. Now there is a cool project that is called Verdasho

00:39 and that allows you to run such a local NPM registry on your machine and point your NPM publishing URL location to that local machine such that then your packages end up there instead of ending up on the public NPM. Now, to help you set this up such that you don't have

00:56 to run this on your own, NX comes actually with a generator to set this up for you in your workspace. And so since we already have the @nx/js plugin installed, so if you go into the package.json at the root here, we have this @nx/js plugin or NPM package

01:13 which provides the versioning logic for Java packages. And this package specifically has also a generator and it's called setup-verdasho. And I'm going to run this now and you can see it creates here a verdasho-config.yaml file. It updates my package.json probably to install some packages like Verdasho itself.

01:34 And then it sets up here such a project.json which is actually nothing else if you haven't seen it yet than the NX version of a package.json script. So rather than having a package.json script defined here, you can define a more, if you want, evolved version that defines your local registry target. So meaning you can run this with NX,

01:52 you can run npx-nx-local-registry and we will do that in a second. And then you have some more options that are being provided to this setup. And so here you can see it runs the port, the actual config that has been created here at the local workspace. So you have now the .verdasho and config.yaml file which allows you to configure Verdasho

02:11 how long the cache is being set up, et cetera, like a bunch of different options. And it also defines where the packages are being stored which is here in temp folder directly in our repo here under local registry and storage. So as mentioned, this is nothing else than a target that we can actually run. So if I now run NX local registry and I hit enter,

02:31 you can see now it runs the Verdasho script and it sets up the registry point to this new Verdasho server. And so if I go to this URL now, I have a local instance of Verdasho running. Now we don't have any packages yet, so let's have a look. So I keep this running, I open up another terminal on the side.

02:48 And since we released the last version at 1.1.0 and we create a bunch of different commits in the meantime, we can actually go and release a new version. And so let's just run NX release and we don't need dry run right now, let's just go through. It creates our changelog and now it asks us whether we want to publish these versions. And so now we can say true.

03:08 And so here you can now see it runs NX release publish. You can see it creates here the different tarballs, it zips up our packages and publishes them to our local version here with the tag latest. And if I move over here to Verdasho, I hit refresh, I now can see all of these different packages have been released with the according version.

03:27 If I go in here, I can see some details like the actual readme rendering, the dependencies that they potentially have, like in this case to core 1.2.0 and a bunch of different options. So when this release process happens, NX actually knows the dependencies via the project graph. And so it makes sure to first publish

03:45 the lowest level project in this project graph, such that if for some reason the release process goes wrong or there is some timeout during the network calls, we don't end up in an inconsistent state where some UI forms package being published depending on a 1.2.0 version of the core package, which never ended up being on npm registry.

04:05 So there's actually some smart logic going on behind the scenes as well that leverages this project graph.