00:00 Alright, so up until now, we basically ran the versioning and changelog generation directly on the packages themselves. So this is our source folder here, it is the packages folder where we have all the different packages. And if you go in here, we basically change directly the version in here. And we also updated obviously the versions here accordingly. Now this is perfectly fine.

00:19 But sometimes you actually want to keep these always at the latest locally, so that if you for some reason miss to update one here, and let's say we have version 1.1.0, while the core package.json actually has 1.3.0, you would actually go and pull this down from npm without maybe noticing.

00:36 So in many situations, what you have in here is always a star, meaning it points to the local directory. And up here, you may just have an actual placeholder of the package.json version. So let's quickly look into that. So first of all, we can go and replace all versions at the top of the packages with a

00:55 version just that is a placeholder. So let me just go and do a full replace here, and do something like this. And as a placeholder, let's just go with 0.0.1. And then let's replace all of these. And so you can see this is being updated. Now let's also make sure this points always to star.

01:12 And so for that reason, I'm going here, and I'm going to just replace this with a star. And here package lock, we're going to exclude. So this looks legit. So let's run this. And now we have basically the star here.

01:30 Let me just run npm install to make sure all the local references in the package lock are also updated. And so now each package has the following structures. We have a version placeholder at the top, and we have here a star. That means it points to the latest version, which is clearly happening locally here. So we're always pointing to the local package.

01:49 So we have a release script, a custom one that we have in here in the tools folder. So we need now to update that to actually copy our source folders to a local directory where we run the versioning. So the first step is to go and update this one here, because what I want to have is I want to have here a build folder, where within that build folder, we have them for each package

02:07 like build slash buttons, where the button source code would live. And inside there that we would want to then run the versioning and publishing process. All right. So to update this one here, let me just add here a function. You can have this being generated by some AI nowadays.

02:23 So let me just get here FSExtra, which we need to install here as a dev dependency. Run npm install here, and then basically this function does nothing else than create this build directory, take the package directory and copy everything over, remove everything

02:40 that has been there before and copy everything over to that location. So here as the first step, this is what we're going to do. We're just going to copy these packages. And for now, let me actually comment out all the rest here so we can just test the actual copying and whether that works.

02:55 So to run it, let's just run npm run release, which runs our release script that we have in a package.json. And so this copies now over all the packages. You can see we have here built packages buttons, and then we have the source code in here and the actual package.json, etc.

03:12 And so now we can version that in that location. Now first of all, let me create some commits here so we can actually run then a release process. So right now we just have this draw release script. Let's add this and let's create here a new comment that's called feature.

03:27 And so we have this committed in case something goes wrong, but you also have now a new comment in our history since the last release, which was here version 1.3.0, and so we can actually get some new release run once this works. So now that we have all the packages here in this custom build folder, we also need

03:44 to go and update our @nx/json configuration, because clearly by default, it versions directly here our packages and reads the version out of those packages, etc. So we need to go and update that. And there is an option that you can use here, which is called generator options. So what is happening here? So the package will define that the versioning should happen in this new folder, which is

04:03 here build slash packages, and then the actual name of the product. So this is the product root, which is packages slash buttons. And so that's what we're exactly interpolating here. And I'm also setting here the current version resolved to point to git tag. By default, it is disk. So by default, nx goes and reads that from the disk from the package json file.

04:21 But we don't have that updated, because obviously now in our packages in here will always be version 0.0.1. So we cannot really use and rely on that. However, if you notice, whenever we run release, we also get this tag. And so we can use that as the source for our latest version.

04:38 You can actually also set this to registry, which would even read it from the remote registry you're publishing to. And finally, I'm setting also the skip lock file update here to true, because since we're not really changing the source code anymore, but rather the build output, there's no point of actually updating the package lock json file here. So we can skip that as well.

04:55 Now, there's one thing that we also need to adjust for here, which is the conventional comments property here is actually just a shorthand, which is an alias basically for a generator option. And so right now, if I run release or release script, it would error saying that we now configure the shorthand notation as well as a generator option.

05:13 And so we kind of need to adjust for that. And the equivalent option there is the specifier source, which can be set here to conventional comments. And so we can remove that up here. You can look that up in the announce docs, obviously. And so now that we have this, we can actually run our release again.

05:30 And now we can see it infers here 1.4.0, which is correct. It does all the tagging and publishing. Actually, the publishing here errors out because we don't have any publish scope defined and we didn't run our local Redasha server. But if we go and look at the package source here, so we'll go into the package file here

05:49 and we see this one here remained untouched. So we still have to start here the version. However, if we go up here into the build packages, we can see that if we go to the actual version part, we see 1.4.0 is in here. Also the core dependencies are properly updated. And so now we can actually go and publish these.

06:07 And this is happening within our build directory here. So this can be deleted every time we don't commit this to git. And so we basically have always a clean source that doesn't get touched, but only during the build process actually get the new releases that are being pushed out. Now that we have the versioning and change of generation properly handled. Now we also need to make sure that we run the release process.

06:26 So basically in our release script at the very end here, we have the release publish process. And we want to make sure this picks up also the correct location of our packages, because by default it will go to the packages folder again. The release publish is an executor, it's basically a runner, a task that is being run within NX.

06:43 And these tasks and their targets can be defined and configured up here in the target defaults. So this is a special one, it's called NX release publish. And we can pass in options to this NX release publish command via the options property in here. And this gets correctly autocompleted here.

06:59 So we have an options part in here where we also set the package route now to build project route. And so with that and the configuration down here that we already did previously, we should now have the whole thing set up. Now let's actually test this out. Let me commit this one here. So we have a release actually to run.

07:19 And then let me run the local registry so we can actually publish it to it. And now let's run the release script that we just created. So you can see it goes to 1.5.0 and then it properly picks up that version and publishes it to our local Verdasha.

07:35 So let me go in here, let me refresh here our Verdasha server. And we should be able to see here that we have now version 1.5.0, which probably was picked up from that new packages build folder that we created.