Since dependencies on other local packages in the workspace are really just symlinks to those projects, we'll run into issues if we haven't ran their build script.
We can make sure that this happens automatically by using Nx's task pipeline features. In our
nx.json we can add a
dependsOn field and set the commands that need to be ran within a project's dependencies.
Instructor: [0:00] In this pnpm workspace, our Remix application in the package.json imports our shared UI. And so, this is basically nothing else than a symlink that points to our shared UI package which in turn in its main property here specifies that there is a disc/index.js file that can be run which will export the compiled output of our button component. [0:24] Now, the thing is if we didn't build shared UI first and we do something like npx Nx dev My Remix app, we will run into an error. Let's go to localhost 3000 drawn our Remix app. You can see we get an error where it says it cannot find that this folder because we didn't build application.
[0:48] Basically, every time we run our Remix app, we need to make sure that we build shared UI first to make this work. Now, this is a so-called built dependency or task dependency. We can tell Nx to automatically do that for us. We can go into nx.json and make sure that in the targetDefaults, we have such a build target specified.
[1:10] We can add here a new property that is called dependsOn, where we say that all builds depend on the build of the child projects or dependent projects. Meaning that whenever we run a build on that's a Remix app, by using the sign in front here, it would also first trigger the build on its dependent projects.
[1:31] We need to define this for the build, so whenever we build the Remix app, but also for the dev command of the Remix app. Let's add a new entry here, new target. We can copy this over such that whenever we run the dev command, it would first run the build on its dependent projects.
[1:49] Now, if we again run npx nx dev my-remix-app, you can see it runs first the target of the shared UI and then search the project. If we go now to localhost:3000 refresh, we can see the application property works.
[2:06] This is a very powerful way of defining such task dependencies, because we need to define the dependencies among the tasks, such as here between the build commands, or here the dev and build command. Nx itself figures out what the actual dependency on the project level is
[2:22] Now, you can also not just trigger child dependencies, so tasks on child dependencies. You can also, for instance, have a prebuild command that you need to run on the project itself whenever it is being built.
[2:33] And so, you could just introduce here something like pre-built without the Hat sign in front so without the sign here and this would mean that when we run something like build on the Remix app, it would first try to run the pre-built script on a Remix app and then go ahead with the build commands.
[2:52] This is very handy for doing some pre-processing specifically, also, on publishing projects.
Is it possible to use remote cache with different providers (not nx cloud)?
You could, by providing a different plugin in the
tasksRunnerOptions. Now I'm biased ofc, but hooking into Nx Cloud is the best choice and a no-brainer, since it is completely free for open source projects, has 500hrs/month for free (no credit card) for all other projects or on-prem installations if you're a huge enterprise. And then you don't just get the caching aspect, but also the capability of distributing tasks across machines dynamically. Something that's unique to Nx Cloud.
What's the main motivation for trying other providers?