Register our Markdown Articles with the Nx Dependency Graph
By leveraging the dependency graph, Nx is able to understand which parts in the monorepo changed and thus trigger actions on those nodes, such as building an app, running tests or linting. This already works out of the box. However, with our portfolio application, all of our markdown articles reside in the root-level _articles folder. Those are not captured by the Nx dependency graph and thus Nx would not correctly detect a change to our Next.js site application whenever we change or add a new markdown article.
In this lesson, we learn how to register our _articles folder s.t. it appears as a dedicated node in the Nx dependency graph.
Prefer to read along as well? Here's the accompanying article.
Juri Strumpflohner: [0:00] Right now in our current setup of our portfolio page, we just have one application. If we run, nx dep-graph, we can see there is just this site app and its various libraries which we have so far.
[0:14] In our real scenario, we definitely would want to make use of the nx affected:build command, such that we can only build, and then consecutively deploy, our site application, whenever something relevant changes to it. Right now, we always would want to have that. Once we have more application, we want to only deploy site whenever it's some relevant changes.
[0:35] One of the main changes we want to hit is our article changes. Whenever we change some MDX content in here, we want our site to be redeployed, because we need to generate the static output for our Next.js application.
[0:49] The problem right now is that the dependency graph doesn't track the _articles folder at all. The reason is, this _articles folder here is really just a folder, and is not a project registered within the Nx workspace.
[1:02] For triggering changes to the dependency graph, we have various possibilities. First of all, we can go to the nx.json. At the very top, there is some "implicitDependencies" configuration object. What this allows us is it allows us to specify entries such as like this one here which translates to whenever there is a change to the ESLintrc.json, build everything.
[1:24] Everything would be affected by that. The reason is simply because if this is a global configuration files on which all of our libs and apps will depend on. This is quite different from our changes in the _articles folder where we would really only want to build our site application instead of invalidating everything.
[1:43] The best approach to do that is by simply registering this as a project. Projects are registered in that workspace.json at the very root of our app. If we close here all project that are already in here, we can just create a new one, which is an empty one mostly.
[2:01] We can create a new one. Let's call it "site-articles". We only need a couple of nodes here. First of all, we need the "root" which would be "_articles". We need the "sourceRoute" which is, in this case, "_articles" as well because it's just really a flat directory.
[2:16] We need a "projectType". This can be either application or library. It doesn't really matter in this case. Let's just use "application". Finally, we have "targets", those are usually the build targets Nx is able to execute. Since this is really just a collection of markdown files, there is not really a target we want to run against this.
[2:33] However, if you might have any future some cleanup tasks or things to do, we could definitely register targets in here and run them against our _articles folder. Now that we have registered the site-articles in here, we also need to make sure to register it in the nx.json. In here, we just add another entry, "site-articles". If we launched nx dep-graph, we can see that our site-articles appears on the dependency graph. It's now actively being tracked by Nx.
[3:04] It is square because we specified the projectType of type application. If we specify this as library, it would be a rounded node in this dependency graph. There's one issue though. Since we're not importing anything from this graph or reading it via its string path, there's no connection between the site and the site-articles in this case.
[3:25] Nx is unable to figure that out automatically. We need to help it a little bit by specifying it in implicitDependencies. What we can do is go to our site and add such an "implicitDependencies" entry and say that site implicitly depends on the "site-articles".
[3:45] If we now again start our dependency graph, we can now see that site has an implicit dependency on this site-articles down here. As a result, whenever we invoke things such as an affected build, site would be affected based on just changes within our site-articles.
[4:04] Meaning, whenever we go inside our _articles folder, create a new entry, or modify an existing one, this would trigger a build of our Next.js application, which is definitely what we want.
Member comments are a way for members to communicate, interact, and ask questions about a lesson.
The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io
Be on-Topic
Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.
Avoid meta-discussion
Code Problems?
Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context
Details and Context
Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!