Adding Tasks to Client & Server Projects

[00:00:00]
>> Speaker 1: Let's set one up real quick, and then we'll go back into talking about the theory again. So, yeah, I just opened up this task list, it's got an express server. It's got a V thing, it's just got enough for me to actually have something useful to do in here.

[00:00:15]
So we can hit our good friend, the Cmd palette. I would just type in tasks. Some tasks are automatic, let's see if there are any in here. You can see that in this case, it did read my package JSON and to a certain extent get exactly what it should be.

[00:00:40]
The nice part is if you wanted to put a key binding on one of these, I mean, you can also assign cubins, we'll see that in a second. You can go ahead and see it, look it made our test.json. That's great, let's start with that. Love it. Npm format is in my package JSON, but it is, again, "type": "npm", "script": is 'format".

[00:01:07]
That's its label, and now it is one of my tasks. So I can go ahead and save and now I can say, if I go to run task, there it is, right? So now the act of running lint or if I wanted even run build, I literally go in here.

[00:01:25]
It's a JSON file, watch this. Put a comma in there. Let's say, yeah, format. What else I got in here? I could just as I wanted to before, we got lint in here. We got lint fix, I love it. So we got, let's do "lint: fix". I ain't gonna whatever, not figuring out what that was.

[00:01:55]
Lint, cool, cool, cool. This one is probably, I could use the eslint problem matcher, but double quotes cuz we're in JSON. So now what I can do is I can go in here, and I can say, task. I've got that format in there, and it just runs it.

[00:02:24]
If I ran it again, it will use the same terminal tag. We'll talk about how to deal with that in a second, how to change the behavior. I can run lint. It'll go ahead and lint all the files, so on and so forth. So now I can do all those things.

[00:02:37]
I could start at the dev server. I could build all the various things, again, these are npm scripts. You need to run a shell command, it's a shell thing. You want to just do node in a certain file. If we look here, I've got server that's just a node file.

[00:02:50]
So we can do one here as well, where we could say, Process is what it is. "process", we'll say, then the command is node And the args are, I think it's, ["src/ Server, .js"]. Cool. What you angry about? Missing property label, that's important. So we'll say, "label": "Start Server", right?

[00:04:01]
You can be whatever you want. So now what I can do in here, you got the start server. It starts the server at local host 3000, right? And so there's a default test task and a default build task as well. And so you can literally just say, build or test.

[00:04:24]
It will run those as well and that's cool. You're neat, that saved me from typing node source/server.js. Great, okay, let's jump back new there. And so we can go in here, where are my tasks? So here's a full out V1 where I've got my lints, I've got my test, I've got build for the frontend and dev server for the frontend, right?

[00:04:57]
Npm, dev, I don't know why. I think, I was just trying to prove a point with the different approaches to it when I was writing it. But then we could have the backend server as well that we kinda did before. This one I'm using nodemon instead of node, that was smart.

[00:05:14]
But what's interesting is you can also make this one called, "Dev: Full Stack". And this one depends on, "Dev Server( API)" and "Dev Server (Frontend)". So as long as it matches the labels. And what this one will do is it will trigger both of them, right? So now I can start up the express server, and I can start up the Vite server at the same time.

[00:05:41]
And you can do interesting stuff in here. So if you wanted to check and build all, you can do "dependsOn:. So "Check & Build All" depends on these other three tasks, but with the order of "sequence", right? So lint it, run the tests, and then go ahead and build it, right?

[00:05:59]
And so now you can kinda do all those things with one command as you go through. And I just grabbed random other examples. If you needed to compile the TypeScript before you run it, hypothetically, you build a VS code extension. What's your take on linting anyway? As long as it auto fixes them into it?

[00:06:21]
Yeah. I mean, it depends. The ones that catch the errors, like unused variables, sure, but those are easily removed, right? How do I feel about lint it when I don't have typescript? I love it when I do have typescript, I mean, some of the value own prettier. There's a lot of overlap in the Venn diagram of those three things, right?

[00:06:49]
It just seems a lot of people just turn it off, you know what I mean? I guess, I can't speak for a lot of people, but I mean, it just seems people turn it off. It all depends. However long ago, when it was the Airbnb, eslint config, which yelled at you for all sorts of stylistic things, and then it wouldn't build versus prettier that just fixes them.

[00:07:18]
Also, as I have aged, a younger me wanted everyone to write code the way I like to code. As I have gotten older, I've relaxed. [LAUGH] Right, if I like arrow functions and Alex likes function declarations, yeah, it's kinda weird that it's a little bit different than the multiple files.

[00:07:39]
But as I've gotten older, I've had to let go a little bit. But in a SvelteKit app, for instance, the lint is also checking for anti-patterns. Or the lint rule in React that says, if you have a use effect that does not have the dependency in it, I absolutely wanna know about that one, right?

[00:08:00]
Do I wanna be yelled at? Cuz we prefer function declaration over arrow functions. That one I'm done with, and I am the person who was the draconian monster with that, right? I was the one everyone else hated, and I have mellowed. So it depends. A Docker build and push one, if you can do it from the command line.

[00:08:27]
You can go ahead and you can also do it from the test as well. This is an interesting one, which I actually haven't used mostly because it was one of the ones as I was researching. I was like, that's cool, yeah. What do you see as the benefit of doing this versus just writing some aliases in a Z shell RC or something?

[00:08:48]
I think having, one again, chaining them and having the different rules about, hey, can these go concurrent? Can they go in order? Could you have done it with an npm script, which is npm run and, and npm run and, and. I think it's only if you are choosing to get to the point where you can just run it from the Cmd palette real quick.

[00:09:11]
Again, when I look at a temporal workflow where I've got to spin up workers and the server and the workflow, that's four things, right? And sometimes one of them are running, I just need an extra worker having dropdown [LAUGH]. My God, honestly, is what it comes down to.

[00:09:29]
Do you see it keeps you more in the code then and looks- Yeah, it's about the flow state. I think, that every time I have to context Shift, there's a chance that I will stop and look at Instagram. [LAUGH] Right and if I can do it in that flow state, we are better off.

[00:09:49]
Do I set up testing every project I work on? I don't, right? But a lot of times in the main app that I work on, a lot of times it's still the Cmd line. Cuz even the tests are there, the Cmd line options still exist and some of you have it.

[00:10:02]
But there are some situations that are complicated, building an electron app where you've got to spin up the electron app with the main process. But then maybe if you are also using a framework, that needs to compile the JavaScript, and then maybe something isn't TypeScript and needs to actually get compiled to become, what I mean?

[00:10:22]
When you get to a certain amount of things, being able to chain them along and just like, run one thing and kind of like, also the problem matchers that we're talking about, like, where you can actually, like, hook it in here and actually see the problems versus, like, parsing now five command lines right.

[00:10:40]
There are certain ergonomics. But like, it is one of those things, which is, like. If it's simple enough, would I ever do this, no.
>> Speaker 2: For a particular project, would you Is there, like, a JSON file where you might kick these off, you know, when the build and when the builds happening, just as a precaution, like as a cleanup, kind of thing?

[00:11:02]
>> Speaker 1: Yeah, I like, it depends because, again, s lot of times they are also running shell command, so your CI/CD might do it. I was thinking about this this morning, which is way too late to think about this. I got to imagine there's got to be a test runner that will also respect the VS code schema and just let you run it on the command line.

[00:11:17]
>> Speaker 2: Well, you know how, like in Angular JSON, for example, you have, you know, you know, all the NPM run. Build stage, build prod, a different-
>> Speaker 1: Yeah.
>> Speaker 2: Something like that, where you could kick them off or something.
>> Speaker 1: Yeah, and I think that this one's obviously a little bit simpler than even my app, but a version of that exists here too, right?

[00:11:39]
>> Speaker 3: And then what's your take on make. I mean, because you can run make from the command line with all kinds of nice options.
>> Speaker 2: Yeah. I'm okay with it.
>> Speaker 1: All the go projects I work on use make seems great. And you can run make from here too.

[00:11:56]
You know what I mean? Like, there are things that you can do, which I don't do, but I feel that I am supposed to tell you about them. Can I do it from memory? Can I do it from memory? So I don't do this one because I again, not because it's bad, not because you shouldn't, just because I am unable to.

[00:12:23]
To match braces. My this one will then run the task automatically. When you open the project. You either definitely want that or you definitely don't. I don't trust that. My ports will be free personally. Fun fact. Just let's get this is like a total aside. But on the topic VS code, maybe it's either VS code, one of my extensions is running on port 5000 so if you run something on port 5000 it's not working blame VS code or one of my extensions, I'm not totally sure, but I'm pretty sure VS code is like something In VS Code is running on port 5000.

[00:13:05]
So if you just arbitrarily pick that port and something doesn't work, that's just a pro tip that has ruined a day of my life. Cool, yeah. And I have never used this one, but the idea that you can actually provide options and stuff like that, again, there's some ergonomic benefits that.

[00:13:23]
You could also build a very nice command line tool if they don't provide the flag, show the options. There's stuff like ink and commander and a whole bunch of other stuff. It's an option. I use it almost always for electron apps. And then as I go down this, a lot of times for temporal workflows.

[00:13:42]
And as I go down the. The list of complexity. I am less and less likely, especially cuz if I use a boilerplate or rest in peace create react app or whatever, you're getting a bunch of mpm scripts, you know what they are right there. There are options here, but I think that the ability to chain them, have the dependence, if you did wanna run it again.

[00:14:03]
When you have them in there to assign Keybinds or even just again, this run task, these are the ones I set up just to be able to like vary. You can pin these to whichever one you really want in this case. And put it to a command so on and so forth.

[00:14:21]
I could see a world where the ergonomics are good, right? Especially if there are a lot of options, so on and so forth, and you want to create a better experience, it is there for you do?