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

The "Watch Output" 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 demonstrates how to implement a watch script that reports changes and errors made within an application during development. This allows developers to easily track errors before pushing code.


Transcript from the "Watch Output" Lesson

>> So there we go. Now we've arrived at something I promised that we would arrive at. We have an app, and it looked like we were building a family of libraries. But really, we were building our way up to an application. And the benefit is, instead of these concerns like utilities type information or data layer, possibly a server if you choose to take this one step further If all of those, if we weren't working with the mono repo, we just have kind of a big pile of code, maybe folders as well, where we could sort of like just dot, dot, dot, dot, you know, reach out and into another folder, we wouldn't have these nice encapsulation boundaries.

We wouldn't have the ability to maybe like a b test. Maybe we choose to write a folder like a server a different way, right? We have two different versions of it. Let's try it with A versus B. You don't have the ability to do that if there are no boundaries around these concerns within your codebase and now we have it In fact, what I can do here Let's see if this is gonna work.

should work Maybe not, all right, I'm gonna need one more script here. And you just copy this and I'm gonna make this dev and we're gonna say type script build give ourselves a different emoji.Are watching the workspace probably is right. So we'll say watch.Preserve watch. Output, Save. And then now we're gonna do our chmod just to make sure it works like make sure this is executable.

Last thing is in our package JSON in addition to the Build. We have a watch. All right, or no we call the dev didn't we? Dev. Those are interchangeable in my mind. Alright, so now we can do Yarn dev. So now what I can do, I can change something in my data layer, let's mess up this API endpoint.

Save Change detected starting incremental compilation, I can go over to a totally different part of the mono repo. I can mess up this type guard, save, change detected, you get your errors. So we have sliced this thing up. But we're not deprived of the same experience we're used to having where all of our source code is watched and An incremental build a quick one at that happens every time we save so we are seeing type guards, type source index ,I think this is a relatively ,this is a method that's not used extensively outside of this package but you could very quickly.

,let me prove this. If I were to do this and I'm gonna actually export it in a weird way I want that symbol to make its way out of the package. And I would expect let's see. No, this actually this won't this won't be the breakage I thought it would be.

I'm basically trying to break one package and show that it will be reflected. As we tried to build the other one, but simply renaming something and fixing it as we export it is not gonna cut it. But let's say I require here a second argument Like strict mode, not with the default would have to be a Boolean.

I keep making backwards compatible changes and that's not gonna prove my point here. Come on, somebody uses his message. Like in the data layer. Yeah, it's showing up here. It's one of these weird things that like a type signature is. Like that strict function type matching thing, it's not picking up on this.

I'm just trying to break something so that it actually makes things problematic. Strict Boolean interesting. It's only reporting things at the site. At the at the site of the error but then elsewhere. Obviously there's a problem here if I were to touch this file. Mention that for some time that it wasn't sure I was wrong.

Interesting. Yeah, I'm not 100% sure what's going on here. Obviously the type checker is objecting configuration the TS config. Yes. I you know what if you're watching this course just pay real close attention to the notes on this section. If I find. Other stuff about this, I'll be sure to, to add it here.

But what we're looking for is the similar experience that you would get with a nice easy to maintain monolith app where you would just say, start up my local dev environment. And then every file you touch,it causes some ramifications incremental build happens. The server bounces, right? And then you see what you need to see on screen.

That is certainly attainable here, and with this with the composite Project Setup, the build process is not it is about as cheap as the the monolithic One thing in one repo approach Getting busted on my commitment. So this would be a UI. Internal dependencies.

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