Create a new empty Nx Workspace

Instructor: [0:00] The easiest way to create and configure new NX workspace is to use its create Nx workspace NPM package. As we can community just use NPX, create Nx workspace, and then we have to give that workspace a specific name.

[0:16] Usually the name is something more generic like the name of your organization, or the name that best describe the set of applications you're going to host in that Nx workspace. In our case, let's just call it Nx Egghead.

[0:31] During the installation, you get a variety of setup options. For instance, if you already know, you're going to host most Angular applications and probably the Angular preset is best for you. Otherwise, you can also do something like React or even a React Express combination.

[0:46] The goal here is to simply do pre-setup your workspace that best fits your need such that you get started as fast as possible. Since I would like to walk you through every single step, I'm going with the empty workspace. Also, since I'm not going to create an angular application here, I'm choosing the more generic Nxcli, that doesn't prevent me though from adding an angular application later on.

[1:09] A final option we get presented here is whether we want to opt into the free tier of Nx cloud. Nx is fully open source and Nx Cloud is the commercial plugin around Nx. Nx has a computational cache, which allows you to speed up things, and within this Cloud, you can actually distribute that cache among your co-workers or within your entire organization.

[1:31] Since, this is a free tier, let's definitely opt in here. Once installation finishes, let's open up the new workspace in Visual Studio Code. Here inside Visual Studio Code, you can already see the layout of our new empty Nx workspace.

[1:47] You can see there is an apps folder, which will contain all of the applications we want to host inside here. There is also a libs folder. Now, libraries in an Nx workspace is usually where most of the code lives and applications simply link to those libraries and reuse it.

[2:02] A library inside here is not necessarily meant to be published on NPM, but it's rather something you can reuse inside an app up here. Another particularity is that you have one single node modules folder for your entire workspace.

[2:16] As a result basically, all of the packages get registered here in this global package JSON, and all applications will use the same version of a specific package. You will only have one version of React for all of your apps, one version of a certain NPM package.

[2:30] That allows first of all to make upgrading much easier because you have one version to upgrade to. You can at the same time having a monorepo verify that all of your applications tests still pass the all compile and work as you expect.

[2:44] Moreover, you don't run into conflicts where you share a library between applications that might use different versions of React. You also see here a workspace JSON. The workspace JSON doesn't contain much yet because we didn't generate any projects or libraries.

[2:58] It basically contains all of the configurations of your projects and allows you to make some adjustments in how the project is being built, word of build artifacts are being placed, and much more.

[3:10] Finally, there's Nx JSON. Nx JSON contains the configuration of your workspace. It contains, for instance, things like the NPM scope that we'll be using for importing our libraries. It contains something like a default branch, and also things like task runners which are the ones based that run all of your CLI commands.

[3:28] In this case, for instance, we operate to Nx Cloud, and so you will see the runner here is now running Nx Cloud but it might definitely differ based on whether you opted in or not.