Launch Settings

[00:00:00]
>> Mike North: So we've already dealt with launch configuration it turns out. We dealt with that when we were debugging. There where two there waiting for you, once was for Chrome, one was or node. And they were the ability to sort of either start an app up or attach to a running app and to potentially like debug in that mode.

[00:00:18]
Launch.json is the file where this is define. It's in your .vscode Settings that vscode folder. Usually, it's something you want to check in with your project. So, I promised that I would break down exactly what's going on here and let's go ahead and do it line by line.

[00:00:37]
So, the first here, type node. That tells us which debugger to use. So you have one launch configuration that's subtype Chrome. Ones that have type node. They've done a really good job without distraction away any job description here. So that means you can install that go like debugger it's an extension that you can install and you can debug go or you can install the Ruby debugger and debug Ruby.

[00:01:01]
It's a very generic thing that can support a wide range of languages. So the request has to do with, now that we know our debugger type, how are we, what is the mode of operation here? Are we asking to start an app up, or are we attaching to a running app?

[00:01:22]
That is what request means. The name, that's for you. That's so that you can see in your menus what this is called. SourceMaps tells this launch configuration that when you're setting breakpoints it should basically use the sourcemap to figure of what really what line should we break on, right?

[00:01:43]
So that's a Visual Studio Code thing, so that it can do that transformation before asking the debugger to set a breakpoint on a particular line. And in this case that's important because, at least for Chrome, like we're not running typescript in the browser, but plenty of that app is written in typescript, so source maps are what sort of allow us to say, in my original code it was this line, we can go through that source map and it'll say, well that was five lines lower down in the eventual code that's running in the browser, so we'll stop there.

[00:02:16]
The port this is usually standard on a path debugger basis 9229, is the standard, is the default for the new node, you know debugging scheme. And then finally we've got protocol here that tells us we wanna use the smarter protocol not the old legacy stuff that was dropped in node 8.

[00:02:40]
>> Mike North: So we talked about type. It's node or chrome. You can others via extensions. Run time executable, we don't have this in our launch configuration yet But this has to do with anything that might have a run time. Like JavaScript. It's not like a C++ built thing where we can just run an executable that's been compiled for our system and we can just let it grip.

[00:03:02]
We say no [INAUDIBLE]. Please start. And here is the program which I wish for you to run. That's how we know there's a run time involved right we pass this program to something and it runs. So a great example of like when you might want to customize this, sometimes there is a different flavor of mode you want to run in.

[00:03:21]
And for example we have got something called available in this project. Which will on a line by line basis as a program is read Transform your typescript into JavaScript, giving you a typescript like node jazz. Babble has the same thing, if you wanna use like ultra modern JavaScript language features, potentially in an older version of node, you can use Babbelnode, which'll do that conversion for you on the fly.

[00:03:49]
And that effectively is you saying, I have a different run time, a slightly customized run time that I wanna use. For running this program and then usually when you specify run time like this, you want to say here is the program that I want to run as opposed to just breaking it up to a command that you running which is the whole thing in one shot.

[00:04:12]
And one of the reasons is if you have restart set to true, you can actually have your app. Like, whenever you hit a break point or something. Sorry, better to say. Like whenever the app dies you basically try to restart it again. An example would be, if you were attaching to your note process and you managed to crash it somehow Your session is done, you're over.

[00:04:38]
Or if you hit that restart button, turns out that you were not necessarily attached to it anymore. If we said restart true, you would basically say, okay, attach to this process. And then as soon as that node thing you were attached to dies your VS code is still there listening on that port for the next sign of life.

[00:04:57]
And as Node comes back up, it'll attack again to it. So it kind of lets you, as you're iterating on code, inevitably, you will crash something, because you're writing code. You have an incomplete function. You accidentally save. This will stop you from having to spin up everything again and start again.

[00:05:17]
It just constantly wants to, whenever something goes wrong, start back up again and try to get into a listening mode. So Console Options, this let's us tell Code where to put the output of this task that we're running by default, you get integrated terminal. You could have output go to the external terminal.

[00:05:40]
So, I heard some comments about people that somehow you're running VS code, and another terminal popped up, and they saw their output there. This could be, this could have to do with that if you have external terminals set up. The integrated console that's just a different panel down here.

[00:05:56]
It's just DEBUG CONSOLE verses the TERMINAL like, where do you want you're output showing up?
>> Mike North: So finally this option here tells tells code how you want that? Now that we've said we want the output to go in this space, how do we treat opening it? Do we never open it?

[00:06:16]
If it were still open, it would stay open, but when we execute this task, do we wanna pop up the terminal? And if so, do we wanna pop it open every single time we restart, or is it just the first time we want to do it? So that's what this option's about.

[00:06:33]
We've already dealt with some of these here. Arguments that is taking care of the quoting properly. You can pass environment variables with env and we did mention current working directory. Here are all of the variables that you can pass in this is straight copy pasted from the VS Code documentation so you can look there if in doubt but these all can be treated as placeholders that are sort of evaluated right at the moment you run your task.

[00:06:59]
And you can see, some of these like the current opened file, that third bullet point down. That is for task that are oriented towards working on something that is, learning in the context of the current line on the current file. Potentially you could have contextually important tasks that are run in that way so you get all that information, even the line number.