00:00 In order to leverage the nx release command on our monorepo here, which is like here in npm workspace, monorepo, we first need to install nx. And we can do that by first simply adding the nx package in whatever is the latest version right now. There is a more convenient way of doing that

00:16 though, which is to run the nx init command. And so I'm just running nx init on this repo. Now what happens here is nx is able to analyze what type of repository we have. It figures out this is an npm workspace and proposes a couple of different steps to go through to initialize

00:33 and configure nx for this workspace. Now for the purpose of just running nx release, these are not as relevant as if you would want to use nx as your monorepo management tool for this repo. But we're going to quickly go over them anyway. So here it first asks like which scripts need to

00:50 be run in order. For instance, the build script should run in order in the sense that if you run the build of a library that depends on another library, you want to make sure that the other dependent library is built first, such that you can actually consume the pre-built output. And so build is definitely something that needs to run in order. nx then also comes with caching, meaning

01:10 whenever you run something and you run it again without changing the actual underlying source or environment variables, there's no point to run the computation again. And so nx just restores it from the cache. And so typical operations here that are cache-based, build for sure, potentially also

01:24 the type check. And finally, you can define different types of outputs. In our case, there's just the standard outputs like dist and build and coverage whatever. And these are already being captured by nx. So we can just skip over the remainder of the questions here. Now if we look

01:39 what happened here. So first of all, in the package.json, we now have the nx package installed. And so that has been added. But we also now have a configuration file here, which is the nx.json, which is mostly like a metadata file for nx in order to be able to fine-tune how it behaves in

01:56 this specific command label here. And you can see we have here the ordering of build commands, which is also called a task pipeline. We also have to define that like build and type check here are cacheable, so they will be restored from the cache. So this configuration here is not really relevant for the nx release part of the course. But given that we have nx installed, we could actually

02:16 instead of running npm run build workspaces, which is a workspace specific command for running the build for all projects here in this workspace, you could actually use nx now for running these tasks. So for instance, we could use run many-t for targets, and we want to have build and type

02:34 check maybe. And so nx would run them in parallel as efficient as possible. As you can see, like the output here is different. And if you would rerun it, again, some of the caching would hit, as you can see here for type check and build, because we have already run it before. Again, it's not super relevant for nx release, but something to keep in mind going forward.