00:00 So to use NxRelease, we can just run the NxRelease command and then configure our @nx/jsON here properly however we want NxRelease to behave, whether we use conventional comments, how the comment should look like, how the version should be increased, etc. Now in most real-world scenarios, however, you need even more flexibility.

00:17 And that's the main reason why Nx also comes with a programmatic API to running NxRelease. And that's what we're going to look at. And so as a first step, I'm going to create here a folder called tools, and I create here a release TS file. Now obviously you can place this wherever you want, doesn't really matter.

00:37 I just find it like very neatly organized if I have my local workspace tooling in a tools folder. And then we can go and import the actual NxRelease programmatic API. And this is done by running here the import from NxRelease, which is the package that we already installed.

00:55 And it has a release version function, a release changelog function, and a release publish function. And so those are the functions we can leverage to then run obviously the version, changelog generation, and publishing whenever we want in our script.

01:12 And with that, we can actually go and build out our function here, our release script. So first of all, I'm going to wrap this in an async function, and then we're going to invoke our different functions that we got here from the NxRelease packet. So the first one here is release version, and I could pass in here options to overwrite

01:29 the default settings that already have been configured within Nx, or which we have configured here in our @nx/jsON. Now this configuration obviously here is still whole, so we're still using conventional comments, but I could go and overwrite this for whatever reason. So I could prompt the user explicitly or based on what we do in our script, I could want to overwrite that. So I have that possibility.

01:48 So for now, we don't need to do that, but rather we need to elaborate on the results that we get back from this release version, which is here, the project version data and the workspace version data. Let's ignore this for a sec here. And so the workspace version data here is an overall version for the workspace.

02:05 And this is for the very specific case, if you leverage the Nx release groups capability. We didn't dive into that, but basically in a nutshell, you can group packages within an Nx workspace and individually define how the version works within those package groups. And then here we will get an overall workspace version, if that is relevant.

02:24 Now we are most interested in this project version data, which contains all the packages in our workspace with the recording, all the new version. So we could elaborate on that and inspect that if we need to. However, in most cases, we can actually just go ahead and pass that along to the next function, which is releasing the actual changelog. So generating a changelog.

02:42 As you can see, I pass on here that data to that function, which then internally knows how to elaborate it. Once you have generated the changelog, most probably you also want to run the release. And so we can use that release publish function. What I get back here though, is a publish result.

02:59 And the publish result is interesting because it allows me to understand whether the actual publishing has gone and worked properly. Because in the end, it needs to access a network, it needs to publish the actual packages to the network. So something might go wrong there. And so I can go and inspect this publish result.

03:16 And what is most often done here with the publish result is actually attach it to the process exit. And so we have here a publish result. And that is an object that gets back with the actual project and the coding code that is associated with the actual publishing process there. And we basically verify whether that has been successful and otherwise we terminate the

03:34 process also in a successful and unsuccessful way. And so with that, we are actually set up, we should be able to run and test our new release script. Now clearly we need to go in our package.json and create an entry of how we want to call a script. And so I'm going in here, calling here scripts.

03:51 I want to have a release script here, which runs our release script, like a release.ts file. ts-node works. tsx is actually a nice package as well. So let me use that one here. Let's quickly install that. And so we have Verdasha here set up locally as well with an x.

04:10 So let me just run, so that will boot up a local registry where we can publish our package to. And then let's try it out. Let's run npm run release, which will now go through release. You can see it goes and associates your version 1.3.0, seems to generate a change log and

04:28 actually goes and publishes as the packages with the latest tag to that local Verdasha server. And so let's open this up. And here we see our Verdasha server, which has all the packages listed in version 1.3.0. If you go in, we see all the details, readme, et cetera, and the different versions and

04:48 dependencies that this package potentially has.