Custom inputs and global dependencies

This lesson preview is part of the Bundling and Automation in Monorepos course and can be unlocked immediately with a \newline Pro subscription or a single-time purchase. Already have access to this course? Log in here.

This video is available to students only
Unlock This Course

Get unlimited access to Bundling and Automation in Monorepos, plus 90+ \newline books, guides and courses with the \newline Pro subscription.

Thumbnail for the \newline course Bundling and Automation in Monorepos
  • [00:00 - 00:09] We've seen how turbo invalidates tasks based on file changes. We can control this in a more fine grained way using the "inputs" key.

    [00:10 - 00:43] For an example, I'm going to go to our apps/frontend-nextjs and open our turbo.json, and let's think about how turbo decides which files should be contributing to our task cache key. The way it does it is by reading .gitignore. So turbo will look at .gitignore and only track changes that are made to files that are under Git's management.

    [00:44 - 00:52] If anything is ignored then turbo is also going to ignore changes to that. In some cases this might not be what we want.

    [00:53 - 01:27] Let's say that for some reason we wanted that the .env* files to contribute to our build hash. To do that we would define inputs manually, and I also always suggest starting with "$turbo_default$", which means the default set of files that turbo will match, which is anything that's not get ignored. And then we're going to add .env.*.local.

    [01:28 - 01:51] And let's also say we want to ignore README.md, and we want to ignore "**/__tests__/**". Let me close the .gitignore file for a moment.

    [01:52 - 02:10] Let's look at this in more detail. So we start with the default set of inputs that turbo will detect, then we say we additionally want to also track changes to this file that's usually ignored by .gitignore, but we don't care about changes to our README.md file or to our tests.

    [02:11 - 02:18] Let's check that this works as expected. I should be able to do "pnpm turbo build" and get one build done.

    [02:19 - 02:34] Okay, then I can go back and go to my RADME file and add some change. Run "pnpm turbo build" and we get a cached build because the README is ignored.

    [02:35 - 02:41] I should be also able to go to our tests file. Add another change here.

    [02:42 - 03:17] Run turbo build and the build is still cached as expected. But if I go to our real source code, and do a real code change in some way. Now turbo will correctly rebuild because it found us changing a file that's tracked. With that, I am going to add my changes to turbo.json and I'm going to revert all other changes that I made.

    [03:18 - 03:34] And I'm going to list the changes that we have after we did, which is to specify "inputs" for this tasks. Let me go to the root of the monorepo and open our global turbo.json.

    [03:35 - 04:00] Similarly to how we can specify global environment variables, we can have global file dependencies that are listed as global dependencies. We could have put our .env*.local dependency here, and that would have worked the same way as we did it by adding it, adding it in our apps/frontend-nextjs/turbo.json.

    [04:01 - 04:27] So it depends on how common a given set of files is to go to your repository that you want to depend on and define manually. If you would put it in a specific task definition or inside your global dependencies. In our case, I'm going to put it in global dependencies and delete it from Next.js, because we can imagine adding dotenv support in other parts of our project.

    [04:28 - 04:45] With this, we now have a slightly optimized build task in Next.js that's going to ignore changes to files that shouldn't contribute to the build. And we have told turbo that if we have dotfiles, those should contribute to caches.

    [04:46 - 05:19] In a real project, I probably wouldn't do this .env dependency globally. I would do it per project only as necessary, but I definitely would do the exclusion of test files for builds because that will make things run just much faster when you have lots of changes to test files that don't necessarily also change your source code, which can happen quite a lot if you have extensive end to end test suites that are catching up to a lot of code that has been written before.

    [05:20 - 05:38] With that, I'm going to add my changes. And I'm going to list them, which we have the addition of global dependencies to our route, turbo.json, and the addition of specific inputs to our build task in frontend-nextjs.

    [05:39 - 05:49] And I'm going to call this "Add examples of custom file dependencies for turbo". Everything passes and that's everything for this lesson.

    [05:50 - 05:51] See you in the next one.