JavaScript and TypeScript Monorepos

Volta Executable Version Q&A

JavaScript and TypeScript Monorepos

Check out a free preview of the full JavaScript and TypeScript Monorepos course

The "Volta Executable Version Q&A" Lesson is part of the full, JavaScript and TypeScript Monorepos course featured in this preview video. Here's what you'd learn in this lesson:

Mike answers questions about Volta and TypeScript versions varying from one working directory to another, and explains that even if there is a global TypeScript version, each working directory can have its own TypeScript version. Volta is a tool that manages JavaScript command-line tools, such as Node, npm, and Yarn. It uploads the correct version for each working directory to avoid bugs, and development or building related issues.


Transcript from the "Volta Executable Version Q&A" Lesson

>> So we got a question from the class, which TSC are we using? And it's a fair question, and here's why, I have a global TSC Let me prove it. If I go open a new terminal here real quick and I go to my home folder, right? I have TSC somewhere, outside the context of any specific project.

I have Within each package, you see you have a little node modules here with dot bin. There's a tsc in here, right in each package. But this one doesn't have one interesting. It's because it's not. It is not stating a dependency on TypeScript compiler here. Doesn't seem to be hurting us for the time being.

And then of course in my top level node modules folder, if I close all this stuff we have in our dot bin folder, there's the TSC. So here's what's going on. There are a couple things that are working together in concert. To make this work really nicely, and let me actually bring this back.

Let me create some nuance here so we can see what's going on. So part of the Installation instructions here had you set up something called volta. volta manages global and package specific dependencies and its job is to make sure you get the right thing, depending on context. So I just installed a TypeScript 397 Now I did this deliberately because I want us to see a difference when we're working inside the project versus outside.

So here's one thing volta is doing for us. We can do TSC dash dash version in my user home folder, I get 397. And if I go back into the project and run the exact same command Let me make sure that this is working the way I thought it would There we've got 403397 and back in the project 403 so you can see here when I call TSC.

Volta is doing some work for us here. It knows it finds that, based on our working directory, we have a package JSON. And that specifies a version of a TypeScript package. So even if we invoke this globally, right, we did not do this. I'm sure you're used to doing this.

This basically says Go into node modules dot bin. Find something there, right? We didn't do this. This still works. This still works. And although it's not strictly necessary for things like PSC, it's totally necessary for things like that. A yarn. Yarn without volta yarn is nowhere in our package JSON, are we using 118 or 122?

We still need to be able to sort of pin that version so we get a truly reproducible build. All right? If a version of yarn is creating buggy lock files, we may, need to. Use an older version that doesn't have that bug we need to pin yarn. So that's one thing that's happening here.

And the other thing I wanna shed some light on is these inner node modules, folders. So note that all of these things that are in the .binfolder like inside types, node modules, utils node modules, they're just symlinks, symbolic links that take you to the workspace level, package or the workspace level node modules.

And you can see, Those sim links right here. So really there is only one jest, there is only one TSC. The reason that they're placed in this local node modules, here is because not every tool in the ecosystem can handle the idea of. Being invoked from a non conventional location, right?

Some things just expect a local node modules to be there, relative to what package JSON and it should just work. So you get symlinks, to ensure that the tools that are more picky about this kind of thing. They, they are happy because they can be found in a relatively common location.

So you can think of this types folder, too many, like CLS and things that would run. It doesn't even feel like it's special thing, right? It just feels like. There's this node modules dot bin PSC or es lint is in there, you know we'll put linting in there in there later on.

So that's why this is treated specially now, for non executable node modules, because those all use the require dot resolve algorithm, which will basically start from. Where the require happens right in that JavaScript file? And it'll keep going to parent and parent and parent and looking for node modules.

Do you have something for me? Is there a node modules? Do you have something for me and keep bubbling up, all of that's going to end up working out with it without any special treatment needed. So that's why you only see these executable things in the dot bin folder.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now