Scripty Monorepo Configuration

[00:00:00]
>> Now we're going to get a little more creative here from for mono repurpose. So I'm going to go back to the workspace level package JSON. And I'm going to configure script D. And I'm going to say, I know by default, you just look for this folder called scripts.

[00:00:15]
But I want to have a place for workspace level scripts and then a folder. Where packages can discover their scripts. So we're going to start with this little config here. And then I'm going to go into our course files. And in folder for step number six, we've got these packages and workspace sub folders.

[00:00:39]
I'm going to drag those right into the Scripts folder that I just created. I can leave great in there, it's fine. All right, so this is what I've got now. And I got to do my chmod thing again, just to be sure I can recursively apply this. And now if you're using Windows right now, you're probably like screaming at me.

[00:00:59]
But frankly I'm not sure how to do this in windows with the permission situation is there. I say this is Microsoft employee which is pretty shameful. But Try out windows subsystem for Linux or cygwin, you'll be able to do all the stuff I'm doing right here. Alright, so the only thing I added here was dash R, which is recursive meaning And I need to do this.

[00:01:27]
Right go into the Scripts folder and all the way down. Set the permissions on these files. So now we can see, the important thing is when we do ls-l, we can see this x. So this means anyone can execute this file is read, write Execute. Finally we just need to kinda wire up our package Jayson so it knows.

[00:02:00]
Like it can, like yan can receive this command and delegate that work to screpti. So I'm just gonna create a bunch of this and we are gonna have field Clean. I'm just matching the names of the folders here are the files within the folder, lint and test. That's in our workspace level and packages, they just get a build lint and test.

[00:02:29]
So we're about to make the same change there. I could have called this Create j s and deleted this. And I believe it would also have worked. But it's maybe it doesn't. Maybe I need to try it again. Let's see if that was the problem. Aha Aha. That's what I get from going off script.

[00:03:03]
Interesting looks like at least for a node, I have to have an extension list file and I have to use this. It's called a shebang interpreter directives. Which is this thing up here? I mean, I can run this I could literally do Just run it like that. Least for JavaScript files, it looks like for shell scripts this.sh is not harmful.

[00:03:38]
So, now that we've got this, take my word for it, we have to do this next step before we test things out. And that is to go into each of our packages and to tell it about scripty and have it. Delegates work for most of these things. To those shell scripts, and we're going to look at those shell scripts in a second because I do not want you to think, I am staying deceptively close to the happy path.

[00:04:18]
Write, easy to set up. And there is no magic it just kinda it works by convention. So the things I've done is I am a package of giving it its own responsibility to define what clean means. But everything else I'm saying Like just build lint and test the usual way.

[00:04:46]
And then finally, normally this would look within each package, it would look for its own Scripts folder, but I don't want that. I want it to go reach up to the top and to use the centralized folder that applies for all of our packages. If we had 50 packages.

[00:05:04]
And we had built lint and test as our script we'd still have only three shell scripts to maintain, do not have to worry about, like things falling out, same package or get a typo one place. Gonna make a similar modification to the utils package JSON. So we're gonna say test scripty, lint scripty and build scripty.

[00:05:40]
And then finally this path, go look for your scripts here. All right, so it's just this little bit and then this bit up here. And I think we're good to go. I see that I have one little bug fix here that I realized at this point I'm gonna let us slam into it because it'll prove that things are working.

[00:06:18]
So if I have delivered on my promise, I should be able to do this, lerna run What should be able to run this? And it should not blow up in my face. Doesn't look like it's blown up. So ran the lint task into packages and I see I've got a little like Nice little awine so I can see this twice gives me confidence that I'm running it in two packages.

[00:06:55]
So I believe that it is delegating its work to this shell script. Why? Because if we go and look in my scripts, packages, lint There it is. There's a little detective looking for the lint problems. And note, this is not anything complicated. There's no special magic here about finding the right directory script is handling that for me.

[00:07:22]
So, it will regardless of where the script is located It will invoke this from within the working directory of where the command was run. So I don't need to wire up any special paths here. It just works. And for that matter if you have scripts that you need to share between your projects,.

[00:07:43]
Going beyond mono repos here, you could put these into an NPM package. And you could reach into your node modules folder. And you could find these and you could run them. So you could have a set of build scripts that's distributed as a package that a bunch of things in your company consume.

[00:08:01]
Totally fair game. Now of course, that means your scripts won't work, until you run, yarn install. But that is not deal breaker, as far as I'm concerned. So, let's try this. Now that we're at the base of our project, what we have accomplished. So let me show you that nothing's up my sleeve here.

[00:08:24]
Building is the same linting is the same. Testing is the same. That's all that we're doing for packages, for workspace building. Well, we've already been doing this. By the way, I'm choosing to do this instead of learner run build, cuz learn to run build simply goes to each package individually and runs build This is a bit smarter and it takes advantage of the, the references that we set up on step two, like our composite project step, and this will update only what's necessary across our whole project.

[00:08:58]
So I'm choosing to do this but for clean And just cleaning, and I can clean with maximum concurrency. Who cares about the order of the packages, we're just deleting. Lint, I want to see the output so I make sure that I stream we've already been running this. And same with test.

[00:09:21]
I'll test things in sequence. Actually, let's make it explicit that the sequences Concurrency one. And here's why reading interleaved test output in your console is just a big pain. So I honestly will have them run a bit slower. And I can read them, but maybe if I was running them locally.

[00:09:45]
And I was just incrementally changing things. I might run them in parallel then because I only expect like the odd tester to to fail. Let's see if we have arrived at a point where this now feels more like a non mono repo JavaScript project. Yarn, build Building workspace and we're done.

[00:10:07]
Yarn clean Cleaning both of our packages, yarn build again. Now it's pausing for a moment because it's doing real work right, it's updating only what's necessary. I just cleaned up to update everything. And then yarn lint. Should do linting in sequence types and then utils and then finally yarn test.

[00:10:39]
There's test number one and here comes test number two. So there we go. Now it's not feeling it's it's feeling like the maintenance overhead is more like a monolith app, cheap to maintain. But we have the benefit of all those little libraries.