[00:00] So this is an npm workspace based monorepo where I have a react application which has been generated with the vtcli and I have two packages. One is a ui package with some react components in it and another one is a pure typescript package with some utilities. To add an X to such repository simply run nx init and This will now ask you a couple of questions to pre configure it for you Once this is done What you will get is a single nx package at the root package JSON and an nx configuration file which has been set up based on the questions you answered. So you can see here caching is enabled for build and we have a task pipeline set up because we mentioned that build needs to run in order, meaning whenever we run a build command it will run the build of all downstream products first. With this in place, NX is able to automatically understand the project graph of your workspace.
[00:52] In this case we have a React app that is pending on the monorepo UI package as well as the utils package. In addition, NX can directly pick up your existing package JSON scripts. So if you want to run the build of this React application, we can just run nx build react app, and it will pick up the correct name, run its dependent products in this case, which is our package util, and then build the actual Vite application. We can also run the build for all the products by using the NX run many command dash T and providing the different targets that we want to run, in this case build. Now if we run this, since we just ran exactly the same builds these will be automatically cached.
[01:33] So by adding an X in this way, you can leverage your existing package.json scripts, but you get a project graph, you get affected builds, so only build what products actually got touched, you also get local caching with the possibility to expand it also on CI via some remote caching. Now NX also ships with completely optional plugins and the only reason they are there is to help you improve the DX when it comes to working with technologies like React, Vite and NX Monorepo. So let's have a look what these plugins provide us. In this case I have already a Vite application so I can go ahead and add the NX Vite plugin. So what this is gonna do is add a new plugin section here in our NXJSON.
[02:18] We also got a new package which is the NXVite package in here. And so now if you go to our Vite based React application we can see NX now detects the runnable targets of this project. Now if you have NX console, the extension installed in VS Code, you can also open up here the inspector for this project and all the different tasks that can be run. We could even go ahead and remove all the scripts from our project and NX is still able to understand from the Vite application directly from the Vite config which different targets can be run for this project. Now the main advantage here is that NX can automatically run the Vite build underneath, it already sets things like the current working directory, It already makes sure that the correct inputs and outputs based on your Vite config are set up for you.
[03:05] And so what the plugin does is basically take away the lower level configuration of the tool in a monorepo setting, such as configuring caching, current working directories, etc. What you can also do is generate and scaffold code. So in this case we have mostly React and TypeScript Monoreaper so we can go ahead and add the NX React plugin for getting some React based code generation abilities. And so once I have this installed I can now generate a new React library directly into my packages folder for instance by using the nx generate command using the plugin nx react and the library generator. You can obviously look this up in our docs or directly use the nx console extension.
[03:46] And so for this demo let me just generate a new package under the packages folder slash my react lib. It will ask me a couple of questions and if you now look at the actual result that got generated it is a pretty clean setup with the TS configs and readme and a package.json that simply exports whatever is being created within this package. And if I don't like this package anymore, since everything is kind of kept local, I can just remove it and I'm done.
