.gitignore & package.json

[00:00:00]
>> Let's get started with building our own TypeScript library. And we're going to do it right inside the workshop project. You should have installed Volta. Here are the instructions. Here's instructions for Windows subsystem. For Linux, actually, it's the same command you should be able to run. If you're using PowerShell, you'd download an MSI package.

[00:00:23]
It's kind of, you're taking on some challenges if you wanna do JavaScript development on like, windows without WSL. Cuz sometimes, like NPM scripts will assume you're running in a, like a ICS compliant environment. Something like just RM won't work as far as I know in PowerShell. So, I would recommend Windows subsystem for Linux.

[00:00:46]
WSL two is crazy fast. It's awesome and it's there. So use it. You may need to run volta install and then request a specific node in yarn version. This is something you would run globally. So this is not saying I want to pin a given version in a particular project, but this is sort of like download, obtain and use this node in yern@ version, and there's a separate command in there you can use to change defaults.

[00:01:13]
So, hopefully you've cloned the project repo. You ran yarn inside the repo so that it would instal all the dependencies. And now we're ready to begin our library. So I'm gonna switch over to VS code so we can make this together. And that'll be the branch I use for this project.

[00:01:41]
So I'm going to enter the packages folder. Sorry, I'll start out at the root. I'm at the root of the project right now as you should be. Let's go into packages, and then within packages, we're gonna make a directory called chat-stdlib. This will eventually become something we import into our chat app and we're gonna put some code in there with some tests, with some linting, and this will come full circle and we'll bring this thing that we're building into that Slack app in a later step.

[00:02:20]
Oops, sorry, I have the folder there. This is the proof that I actually tried this stuff and ensured that it works. Okay, so let's enter this folder. And now, I'm gonna run a command using npx. Who knows what npx does? Yes sir.
>> It invokes the bin for a particular node package without having to have a package.json and invoke it.

[00:03:06]
>> Exactly.
>> npm run.
>> Exactly, so what this lets you do is, first of all, NPX is useful when you're running an NPM package that has some sort of executable script in it. So you wouldn't want to do like NPX low dash, right? NPX lodash would download lodash on the fly, and it would say, run a command called low dash from the lodash package, and you'd get an error saying, well, let's try it.

[00:03:37]
Why imagine what the error is gonna be? Could not determine executable to run. There's no executable in this package, but gitignore has an executable. So we could do this. So this is equivalent to like running npm installed-g gitignore like go grab the package for me and then running the gitignore executable.

[00:04:10]
So this is like a CLI package that's published on npm. So we can prove that this works by writing npx gitignore --help. We should see some reasonable, oops, maybe not. An unexpected, a wrong flag provided maybe, maybe ---help isn't a supported here. Let's just try it. Let's pretend we went to the documentation and we looked at what this gitignore package does.

[00:04:35]
It turns out this creates a dot gitignore file for us. And you can provide it the name of like a language or a framework. And so this is going to create an awesome gitignore for like JavaScript and Node projects. You could use Python here or Golang or whatever you want, but it knows sort of based on that type of project, what are the common folders that shouldn't be checked into Git.

[00:05:03]
If we look at our folder here, I'm gonna close this up, chat standard lib. Look at this, it's got like a bunch of yarn specific stuff that it's gonna ignore. It's got code coverage that it's gonna ignore, grunt files, Bower components. This is all very JavaScript specific stuff.

[00:05:21]
Node and jspm modules. Ts build info that's a type of build cache. So we're gonna see that pop up in our repo today. It's very good that we're ignoring that this is all stuff that should not be checked into lint. So there we go. We have a great gitignore file that handles everything we care about and more.

[00:05:41]
Like, all of this stuff is great. Some VS Code specific stuff. So, every language has a bespoke gitignore like this.
>> Chad said, didn't know this, super cool and useful to save some time for show.
>> Yep, it's more things. This will contain more things than you will think of if you hand draw gItignore.

[00:06:04]
And remember, once you accidentally check things in to git depending on your settings, you may not actually get to remove those from your git repo. They're still in your history. There's still, you know, things that you potentially have to check out. So now the next step we're gonna take is we want to package JSON here.

[00:06:22]
And we could hand roll that too, but yarn provides a great command here, yarn init. And I'm gonna run --yes. So if you ran yarn init without --yes, it would ask you a bunch of questions about, what's your entry point file? What do you want the name of your package to be?

[00:06:40]
What's the initial version? What kind of license do you want in your package JSON? We're just gonna have it go through and make some reasonable assumptions, give us a really simple result. And this is all it did. So we have a package JSON now, but it told us exactly what it is.

[00:06:57]
So we have a name and then it's put, this is like just a yarn feature where it keeps track of what package manager you wish to use. We don't need to worry about that. But now we have package JSON. And we're going to add a couple things to this.

[00:07:12]
So first, we need a, we need to indicate like the entry point of our package. And we're gonna do that with main. Dist/index.js, we're gonna end up having TypeScript source code in a folder called SRC. And we're gonna have the build output in dist. And if you were to look through that gitignore file we just created, it's so common to have a folder called dist that you don't want to check in to your git the like it's already get ignored for us.

[00:07:51]
All right, we're also gonna add, we will add a license. And this we're gonna say no license. If you wanted to make this MIT license, you do this whenever you want, for this context here where we're sort of including this library as part of a larger app. This is never gonna really get published to NPM, so we're not gonna worry about this.

[00:08:18]
In fact, we could ensure that. I don't have this in the instructions, but it shouldn't be harmful. Private true. What does private mean? If set to true, NPM will refuse to publish it. Now we have a safeguard ensuring that someone will have to remove this line in order to make this work.

[00:08:41]
All right, GitHub copilot knows where I'm going next. [LAUGH] We're gonna create some scripts. So I'm just gonna change these around a little bit. So for build, we're gonna run yarn tsc, I don't know if this is necessary anymore, but it's certainly not harmful. Yarn tsc gives me confidence and I'm running the TypeScript compiler version in this repo, the right version of this TypeScript compiler.

[00:09:10]
Sometimes my experience has been that it could just be with older versions of yarn. If I were to just do this and maybe I like forgot to install TypeScript in this repo or something, it might run like a globally installed version of TypeScript, and I have been trolled and confused by that kind of problem enough in my life.

[00:09:31]
I've decided I'd never want that to happen again. Let's get rid of this cuz that's not how we're gonna do start. We can take care of test here, though. We're gonna do the same thing here, yarn, jest. We haven't installed jest yet. We will, we're just taking care of all of our yarn scripts up front.

[00:09:52]
Okay, we're gonna have actually don't think we need the dev script. There's one in the notes, but I don't think we really need it. We do need a lint script. I tend to just put them in alphabetical order. Cuz then when you code auto format, you don't get what a bunch of thrash where someone has to stare at it and be like.

[00:10:14]
Something change here or is it just shifting lines so yarn eslint and then we're gonna say we want to lint the source folder and we want JavaScript and TypeScript files to be linted, this is just file extensions. Eslint was built for JavaScript originally, I think it's still by default Lint's JavaScript only, but this is one way to get it to sort of start paying attention to ts files.

[00:10:47]
And that's it. So if we were to describe what each of these scripts does, this should build the project. This should lint the project, right? Checking for code style, best practices, things that sort of go beyond the type checking. And this should run tests, like we're gonna have a test that's written with Jest as the runner, and this will make sure that that runs.

[00:11:11]
Make sure you save this file at this point. Because now we're gonna do something with Volta to that will modify package JSON. So make sure you're in this chat standard lib folder, and you're gonna run Volta Pin node@lts. The latest lts of Node is Node 18.18.2. If you look at Node's release and versioning policy, they always recommend you use the latest lts in production, not the latest version of Node.

[00:11:51]
And then yarn@ latest major version of, sorry, latest minor version of yarn 3. You can think of these just like sort of package JSON style versioning constraints. You run that, and we should see something pop up here. If we see an error and it relates to networking, it may be because Volt has not been fetching node packages this morning, like bundles of node and yarn.

[00:12:29]
And I suspect that's what's happening here. Should be nearly instant, so I'm gonna try it one more time. All right, normally this would work, but I'm gonna do manually what this would do. And it should be fine. We can go to the root level package JSON of the workshop project.

[00:12:52]
Grab this, we're just gonna paste that into our libraries package JSON. Copy. Paste. So the reason I'm doing this is you potentially could end up like, if you want to upgrade Node in a large scale piece of software, let's say this is like a Node.js backend of some sort, like it's big API, you might wanna test different Node versions.

[00:13:32]
Locally in little sub parts of your of your repo and you could start bumping this up to 20 and see how that works out. And then this would let you run tests in that new node version and things like that without having to necessarily like change the whole repo.

[00:13:49]
This is gonna be a common theme we have here where we don't wanna be changing settings or having like big switches that were flipping for a project of like 100,000 lines of code. You wanna be sort of operate locally and validate, and then start to apply that change more broadly and validate there.

[00:14:09]
We don't like big banks, they're risky, and if they don't work out You can create stoppage for every contributor to the team and when that number is big, it's a big problem