Local Packages

[00:00:00]
>> So we have two more things left to take a look at, and the first is dealing with local packages. This is where we're getting into modular architecture, and what we're gonna do in this chapter is bring that library that we created together at the beginning of the workshop, chat-stdlib.

[00:00:19]
We're gonna bring that into our chat project and in doing so, demonstrate how you can just use yarn and get a lot of the benefits of a mono repo. This is something you can't do with yarn1.x. You need to have a modern version of yarn in order for this to work.

[00:00:36]
What we're gonna look at first is like how does yarn understand that we're working with a mono repo here? So we'll look at the root level package json and this is very important. When we're dealing with yarn workspaces, and have a workspaces property in our package json that is describing where all of the packages can be found.

[00:01:01]
Where you call each one of these things a workspace, where the various workspaces can be found. This is a convention that a lot of people follow. They have packages slash, and then every subfolder of packages ends up being its own workspace. So I'm following that here, but you could make this whatever you like.

[00:01:21]
And what that means is, if we close this up a little bit, These are all different packages here. So if you've taken TypeScript fundamentals or intermediate TypeScript, here are our notes for those two courses. This is the course website. This is a fundamentals little like hello TypeScript project.

[00:01:40]
Here's that HTTP error. Dependency we brought in that didn't have any type information, but it had this like HTTP error class. Turns out that has been in here as a workspace. And now we're gonna work with these two. We're gonna bring this package into this one here. The benefits will become pretty clear as we do this, but the first benefit we're gonna, I think we already see, is you get encapsulation.

[00:02:08]
Here or publishing package, but we're building a dist folder. And it has a very deliberately created DTS roll up where we can say this is a private thing that one should be able to call this. I can opt into beta features. So you could have some stuff in here that sort of internal.

[00:02:28]
You're managing complexity by doing this. We'll see other benefits in a moment here, but for now let's bring the package in. So we're gonna go to chats package json, and we are gonna add a new dependency here. Chat. Standard library, and that's pretty accurate there. Workspace:*. So this is the special yarn workspace thing.

[00:03:01]
NPM will not understand this, so don't try to use this with NPM. Or you're in for a bad time. This you can think of as kind of the same, you can do like this. It sort of relates to defining how this dependency will float forward. It's not actually important in the context of this project because for this to matter, this character here, you'd have to be publishing this stuff to NPM.

[00:03:32]
That's where this starts to matter. What version of chat-std lib does chat need, like if they were both libraries? That would be defined in terms of this. Whether you'll accept a major version or a minor version, change, that's where you'd find that. So, we're going to need to then run yarn.

[00:04:00]
Because it's gonna wire up dependencies. Some representation of this, I believe ends up in, maybe not, just gonna say could end up in the lock file, but I guess just having it in the package json is sufficient. Sorry, I didn't save this How I've indicated. So we can look at what we see there.

[00:04:25]
Sure enough, there we go. So it's saying, You could just see that it had some effect on the yarn lock file. I'm not gonna try to read through a lock file there. So the next thing we're gonna do is delete a few files from our chat app because we're not gonna need them anymore and we're gonna depend on the library we wrote to deliver these.

[00:04:54]
So they're gonna be in the utils folder. We'll delete error, it's gonna be deferred an error. So delete those. And then we can delete their equivalent tests because we have test coverage in the library itself. So in tests, utils, there's deferred and error, getting rid of those. Cool, now, we're gonna go into our networking TS file.

[00:05:29]
This one here in our utils folder, which is currently very unhappy because it's missing its stringifyError thing. And here, we're just gonna to say, chat-stdlib, there's stringifyError. It has no exported member. I think some of you might know what we'll have to do there, and that is opt into the beta.

[00:05:56]
So we'll go into our tsconfig. Actually, I'm just gonna copy it cuz we already did this work for the tests, for this little library. Right here, we're just gonna need this line, to get that beta stringifyError function, we got to point it to the correct types. So, I'm going to apply this to the outer, that's the test's tsconfig.

[00:06:25]
I'm gonna put it in our main tsconfig. So we already have a paths object there, we can get rid of that, Add a comma, all right, I'm just gonna think carefully about what the relative path is to get to that file. So I'm in packages > chat, so I wanna go one up and then into chat-stdlib.

[00:06:50]
So this will get me out to packages, and then I'm gonna enter into chat-stdli/dist, and then there's the beta. And go back here and the error is resolved. StringifyError is coming through. There's the beta annotation there. So we're now consuming this as a dependency. It's as if it's in our node modules folder.

[00:07:13]
Pretty cool. So we just did the beta types. Let's just run yarn type check. I bet there's more. There's got to be. Maybe this one. Sorry, it's time checking the whole repo now. There it is, api.ts. It needs deferred. We're gonna bring that in from chat standard library, and it'll resolve cuz it's in there.

[00:07:55]
That should be it. I thought this was just like a two-liner. Yep, there we go.