TS, Go & Rust Project Structure

[00:00:00]
>> So one quick thing on structures, I think everyone's pretty much familiar with TypeScript structure, right? You have your node modules, the weight of the universe. You have your source folder pretty much where everyone keeps it, I think some of the older projects on JavaScript. I'm thinking of the Bunyan Logger that uses lib, but lib's kind of out of fashion these days.

[00:00:18]
And of course, you have package.json, and then a bunch of other files. You get that, a bunch of configuration. Golang, we kind of went over this a little bit. You have a command folder. This is where your main functions go. If you have subfolders in your command folder, you can have multiple kind of binaries with main entry points.

[00:00:34]
And so that tends to be the canonical structure. I believe there is even something called the canonical Go project structure. And they're still arguing over what you should be doing. Standard Go Project Layout, that's what I'm getting most of this from. And so in my kind of reality, this is what I tend to use, which is command, and then package.

[00:00:55]
And then I have subfolders, and those are the export names. You'll notice that we did strings lowercase, and then some functions on it. So if we had package strings with some functions, we could refer to that package strings as opposed to the standard definition strings if we wanted to.

[00:01:11]
So this will show up in your project as an importable name. So just something to think about. And it'll use your LSP to type it all out for you. And go.mod kinda tells you what your project relies on, your basic bookkeeping. You can think of it like a package.json, very, very similar.

[00:01:27]
Rustlang, exact same kind of, it's like a mixture of Go versus TypeScript. You have your source folder, which contains all your source. Often, how I structure all my projects is I'll have a lib.rs. This is how you can export a bunch of different files with all their stuff into your binaries.

[00:01:48]
So I simply will have a lib.rs and I'll have a bunch of, did I put an example here? Yeah, I'll have pub mod file_1, pub mod errors. And you can see it right here and it just all works out. I think I typed this by hand. It shouldn't have .rs.

[00:02:02]
I actually put .rs on there and I think I typed it by hand, my bad on that one, but you get the idea. You can see file_1 right here, and then we export it from the library. That means our binary can then include our package name, ::file_1:: whatever structs stuff you have on there.

[00:02:21]
So very, very similar, they all effectively accomplish the same thing. I always use the bin folder cuz often I'll have multiple binaries. If I wanna test something, just like a manual test to see how this thing works, it's always nice to have your project set up that way.

[00:02:36]
So that way, if you need to do that, you're not, crap, I gotta restructure stuff.