Visual Studio Code
-
Top 5
I really love to code and sometimes the ideas just come so fast to my head, that I just can't wait to get them down into the editor. So I need to make sure my editor can keep up with me and do everything I need so it doesn't block those ideas from coming out. And that's one of the top reasons I use code as my editor. When we choose our tools we each have our own reasons for doing so. So let me share with you my top reasons for using code. Number one, code is fast. I mean I love how lightweight this tool is. It's so fast it opens fast and it's multi instant, so I can have multiple instances and toggle between different projects. Sometimes I've got four or five of these open. Need a new one? Great, just open a new instance or go to terminal and do code, bam, opens right up. I don't see any spinners, I don't see any funny messages about please wait and it's great because it just gets out of the way. And that's important because, well 1b on my list is I'm faster with code. I'm just love how fast the tool is. I can edit fast, I can debug fast, I can navigate fast, and by the way, have I said it's fast. When I'm writing inside of code, I feel like the tool is letting me get my thoughts out of my head and get them down quickly. It's a much more fluid process. Alright, so number two. Code is cross platform. This is great because a lot of times I work on a Mac in OS X but I also have to flip over to Windows on my Linova. So it's really important for me to be able to work on both platforms. And the people I work with on my team, they work with a variety of different kinds of machines. So whether it's Linus or OS X or Windows, I know that codes can help me out. Number three is that code has a debugger. I can't tell you how many times I've been sitting and looking at some Node code and kind of resisting going and debugging it through Node inspector. Or cranking up another tool, because I don't feel like waiting for it to get ready to debug. Code makes it easy to debug. Got a problem, set a breakpoint, press run, bam there we go. Number four, code has rich Intellisense, so whether I'm in C# or TypeScript or JavaScript with ES5 or ES6, I'm using JSON, it's great because I get all this Intellisense and autocomplete. Not to mention all the hints and the hovering and other features that you get. And well, number five for me is kind of a cop out, it's really a bunch of features all in one, because code has a ton of refactoring features. This just makes it easy to change code, because I'm convinced that, I don't know about you, but I spend more time changing and reading code then I do writing it. So I write my code and then I have to tweak it and change it or refactor it. So it's important to me that my tool makes it easy for me to refactor. And I can run tasks in there, like Gulp or Grunt, directly from VSCode I can go to symbols or files or tasks, look at all references, it makes it just a keystroke away for anything I need to do. And sometimes code will give me a hint that maybe it thinks I should be refactoring something. It just puts a little lightbulb up there. And when you're working with all these different kinds of technologies and frameworks it makes it an easy choice to use a tool that can handle all of them. And if you're looking for the 15 second elevator pitch on why I use code, because to me it sits perfectly in that sweet spot between the editor and the IDE, for most of what I do in my development workflow. So that's an important piece there, the editor and the IDE. What is the difference between those? Well let's take a deeper look at that.
-
Editors and IDEs: Where Does Code Fit?
I've used a lot of different development tools, including Sublime, Brackets, ATOM and Code. And I categorize all these as editors. They allow me to do a lot of text editing and code editing and move along fast. I've also used some more IDE centered tools, like Webstorm and Visual Studio. So how do we categorize these as editors or IDEs and really what's the difference here? Well there's quite a big difference actually. They all allow us to do development, like Visual Studio code does, and some of them run on cross platform, like Windows. And some of them run on a Mac, but when we look at the spectrum of editor to IDE, we can kind of break this down into different categories and features. And the most common characteristics and features of an editor that you find, is that it's lightweight or fast or it handles a lot of different files and folder structures. It doesn't have to be project based, you can just point it at a folder and go. They often support many languages. And the languages can be development languages or just simple things like markdown. It also allows for many different kinds of workflows where you might want to work in this tool for this kind of workflow, maybe you flip over to terminal for another. And use a different tool for another altogether. And how you use the tool usually is up to you with an editor. And quite often, they're all keyboard centered, which means you can keep your fingers on the keyboard and move a lot faster. They don't generally have things like wizards. On the other side of this spectrum, we have IDEs or integrate development environments. And while they might work off files or folders, usually they work off some kind of project system. Like a solution file or a project file. And they generally have code understanding, so they know that you're typing C# or they know you're typing Ruby or JavaScript. So it can give you Intellisense and other kinds of features. They often have debuggers built in. Need a build process? Sometimes you can just right-click and it'll actually create a build process or press a button. What if you just forget a keystroke somewhere? Well in an IDE you usually get buttons and wizards. They'll often have designers and drag and drop features, ALM integration, CICD, platform tools, whole bunches of things. Need to push the Heroku or Azure? No problem, here's a button for you. So some tools fall on this side of the spectrum and if you want all those features, that's where you're going to end up. Tools like Visual Studio or even Webstorm fall into this category. But for me that sweet spot is right about here, because I want a little bit of the IDE features but I want a lot of the editor in that speed. Because the more features you get, like in an IDE, often it kind of slows things down, because you're not using everything in that tool. But you have to wait for all those features to be ready and available. And that's what VSCode gives us, it gives us that lightweight and fast features mostly based on files and folders, but it is able to work as a project context, like a C# project. Or a TypeScript project or even a JSON config. And it still supports all those languages and is keyboard centered so I can move really fast, but it does have code understanding of some of the languages and it allows me to the do cool things like debugging and running tasks. So where do you fall in this scale?
-
Under the Covers
With all these features in mind, code was designed with a goal. And a lead engineer on code, Erich Gamma, of the gang of for fame, said that VSC is a new choice of a tool that combines the simplicity of a code editor with what developers need for the code edit debug cycle. And his quote really sums up that spectrum of editor to IDE. You want your editor to be simple and easy to let you code, then edit it, refactor it, and then debug it. So let's take a quick peek in how they design this. There's three main parts to code. First you need some kind of UI framework and for that they use electron or the ATOM shell. It's a great developer tool that the ATOM editor is built on. Second, they need an editor itself. And the same folks who built code actually built another on line editor in the browser called Monaco. And then finally, they needed some kind of brains, they need things like TypeScript and OmniSharp and Roslyn to be able to help get that great rich features that you get with the languages. So let's take a look at each of these. The cross platform UI shell. Now that comes right from the open-source library Electron, which is formally known as ATOM shell. The GitHub team made this and open sourced it, so why did they use this? Well it's very popular and well built, it's cross platform, automatically updates, and behind the technology is Chromium and Node.js, which made it a good fit. But they also needed a battle hardened editor. So for this they leaned on some of their prior experiences in the Monaco editor they built for on line. So these guys are no strangers to building editors, as you can see Erick actually had a hand not only in Monaco, but also in Eclipse. So the editor tools that you find in Visual Studio online, also being used inside of Internet Explorer and OneDrive, all contributed to what you're seeing in code, including some of the git features that you see later in this course. So thy lean on Electron for the UI framework and on their editor experience. And the third part is the brains, the tooling. That gives us the Intellisense and the debugging. For that, they're using TypeScript server and OmniSharp Roslyn. When you put those three things together that's what make ups VSCode.
-
Cross Platform
When you start to use code, make sure you grab the right version for the OS that you're using. When you go to the code homepage, it should automatically detect your operating system and prompt you to download the right version. But you can always go grab the other operating system versions as well from the same page. There are a couple of subtle differences in how code operates on these different operating systems. And to understand that, first it's mostly about the key strokes. And since code is heavily dependent upon keyboard bindings, let's take a quick look at different key symbols we're going to use in this course. When you see this character of up arrow, it means it's a Shift key. And then when you see this, that's the Command key on a Mac. Often when you see the command key on a Mac that often means it's going to be the control character on Windows. And speaking of control characters, this character here represents Control and this guy down here is the option or Alt key. When I use a lot of key strokes in the course, I'll be showing these so you can see which key strokes I was using. And when in doubt, always go to the command pallet. You can search for commands and see the associated key strokes for your operating system. This is the single most important key binding to learn. So on a Mac to get there you can do Shift + Command + P. On Windows you're going to do Shift + Ctrl + P. And on Linux you'll also do Shift + Ctrl + P. If you're going to remember any single key binding always remember the way to get the command pallet. Because from there it's like the central hub of all the features in code.
-
Resources
If you're going use a code editor, you need some code, right? So the good news is you can use any code you like, but if you'd like to follow along with the same samples I'm using in the course, by all means feel free to go out to GitHub at this link or this short link here at the bottom. And you and download the code or you can forward my repo. But beware they're really simple applications. The code in there is not what's important, they're just there so we have something to follow along with so we can try out using Visual Studio Code. Feel free to pause while you go to do that. I'll wait for you. Okay, now we'll be looking at a variety of different languages and platforms throughout this course. While they're not the main focal point, if you're interested in learning more about TypeScript or Angular, or Gulp along the way, feel free to check out my other courses here at Pluralsight. And if you find that there's just a feature you can't live without with Visual Studio Code, or you want to report some kind of a bug that you found, you can jump up this link right here. You can also follow them on Twitter and they also have a special group called the Insiders group. All you have to do is go to this link here at the top, sign up to be an insider, and they'll add you to their insiders list. Which means that you're going to get access to the next version of code, usually a couple days before everybody else does. And it's free to sign up, so why not?
-
Get up and Running with VS Code
Get up and Running with VS Code
Visual Studio Code is a smart lightweight and fast cross platform coding editor. Now it's time for us to get started with code and install it. Then we'll set it up and we'll get comfortable with the layout and the tools in code. The first step, of course, is to go and download Visual Studio Code. And we'll do that from code.visualstudio.com. And here you'll see a button right at the top of the screen, just like this. Now remember you can download this for OS X or Windows or for Linux, so make sure you pick the right download for your OS. So let's flip over to Chrome
-
Downloading and Installing Code
And you'll notice we're right here at code.visualstudio.com and notice that it says download code for OS X, all ready for me. That's because I'm on a Mac, so it knows what OS I have, so you can just click that button. If we scroll down to the bottom we can actually see that they got Linux and Windows down here too. So you can click on those versions as well if you want to get all three. But for me, let's go ahead and click on the top button and for you guys you should do that too. We'll download that, notice it's about 61 MG, and hopefully it downloads pretty quickly for you. And then you can open that zip file up and then on Windows you'll just double click it and install it. And on a Mac you'll drag that over to your applications folder. Now that it's been downloaded, we'll open that up, and then we'll drag it right over into our applications. Now for me it's going to ask me, hey do you want to replace it, because I've already got a copy of it here. And that's fine for when you get updates as well. So I'm going to click Replace. And then I go over into applications and let's right-click on Visual Studio Code because the first time we open it, it's going to prompt you for message say, hey it came from the Internet, would you like to trust this? And we're going to say yep. And then it's going to open up Visual Studio Code for us. And you can see how quickly we can get started.
-
Command Line Options
Now that we've installed code, let's set it up on our machine so that we can open code right from a command line. If you're in Windows, the good news is that you can do this right from a command prompt just by typing code and then dot and that'll open on the current folder. If you're on a Mac, we're going to want to set this little bit of code up inside of our bash profile. And you can find helpful commands like this right at the code website. Once we have the command line setup, we can do things like type code. right here and it'll open up code for us. But there's other options too. So let's say you wanted to go ahead and open up the file in the last active instance of code. You can pass in the file name and --r to open up in that last instance, it'll reuse it. But maybe you want to open up in a new instance of code, so you can have multiple instances side by side. Now I really like this option, because there's lots of times where I have many projects open up very different ones, where I want to look at different code. So it makes it nice and easy that I can open Visual Studio Code by typing in code and then the path to that folder and then --n. And there's another neat option too, and this is great for when you want to open up to write at a particular file, line number, and a column possibly. And you can do that here with the --g, the file name, and then colon and then the line number and then optionally the column. This is also a great feature if you have any tooling that you want to write that'll automatically open up, for example, a bug right into one of your code lines. Maybe you've got a CI process you want to code that into. So let's go try this out.
-
Launching 1 or More Instances of Code from Command Line
The first thing we want to do is go out to the code website and we're going to go into the docs so we can grab a little bit of code that's going to help us out with setup. So we click on docs then over on setup and you can see down here, if you're running a Mac, you might want to grab this line of code. And if you're running Linux you can grab this line. Now for Windows you don't have to do anything so if you're in Windows, just watch along, if you're in Mac, let's go ahead and grab this little bit here just copy and paste. Now we're going to come over into our terminal window and I'm just going to open up with an editor my bash profile. And there's going to be a plain old editor, it can be anything you like. And I'm going to paste that right into there and save the file and then I'll close it out. Now you can use any editor you want, could even used code to do that if you'd like. And then next, let's go ahead and source that file, this is going to make sure that that command is accepted. So now that our bash profile is ready to go, let's take a look what we actually did. So the Visual Studio team here is giving us a little snippet to say when you write code, it's actually going to open up VSCode and it's going to accept the parameters that we just talked about, so we can actually crank it up with whatever settings we want. Like to a specific file or to a specific folder. So let's try this out. Let's use code to actually form our bash profile. So instead of saying open bash profile, let's take in code and then bash profile. And there we go, code opened up on the left hand side. So here you can see the same bash profile that we had before, but now opened up inside of VSCode. Now I'm going to go into a folder that happens to have some code in it, my folder is going to be called _git like this but you can go in any folder you would like. And I have this one called Gulp patterns. So let's take a look inside and see what kind of code we've got in here. So I can see I've got a folder called source and then inside of there I've got some other files on open. So I don't actually want to go into that folder, I just want to show a trick where we can go and look inside a source and we can see in there that we've got a client folder and an app folder. And in there there's a couple different files and folders. So if I wanted too, I could say, open up with code and now here I can type in that path, I can say use source and then go into client and then app. And maybe I want to open up the app module js. Now if I do this with the --r, it should open up into the same instance of VSCode that I have at the bash profile. To see that over here I can open the Explorer on the left by clicking the top icon, which we'll learn more about. And then here we can see the bash profile and app module js. Now if I make this a full screen, we can take a look at both of these at the same time. We need a little command short cut here, I do command 1 and command 2. Command 1 means go to the first window in the editor. Command 2 is going to open up a second one. And notice I now have two files open. So now I can click on the second one and open the bash profile on the right and the app module on the left. Now let's close both of those, I'll go back into command 2 here, and then I hit command w or I can hit the x and I could also do command w to close this window or I can hit the x there. And those commands will work on a Mac and for Windows you can use the appropriate commands to close those windows too. So let's go back inside of terminal and now let's try to open up that file to a specific line of code. So here, instead of saying with just --r, we could also do the --g. And now let's go back into the file and say let's go into, let's say line 8 and we'll go to column 10. And we open that up and when it opens up, we can see we're on exactly that, line 8, column 10. And we can look at the bottom of the screen, it shows us that and also, if we move around we see where everything else is. So let's try one more thing here. Let's say I want to open up another whole project. We'll go back one folder. And let's open up another project. This one here is called hot towel angular typescript. And for this one let's just type in code., but I want a new instance so I'll type in --n. So I hit that in there and we get a new instance of code. So we can see side by side now, it's a great way that I could open up an instance on the right here with hot towel angular typescript one project I happen to write. And then another one on the left, with maybe just some various files that I have open. And I can also go over to the one on the right and add more files to it or open up a specific folder. Just by browsing by clicking on the button here. So I can go in there, click on the button, and maybe open up another project using the IDE. So there's various ways here to open the files and folders, all of them pretty easy to do. You can either use the mouse and use the menu items or you can open up different instances of code right from the terminal or your command prompt.
-
VS Code Layout
Now that we've got code installed, let's take a lap around all the different features inside of the editor. We'll take a look at the layout itself and the different features we have like editing of course and the explorer on the left hand side where you find all of our files. Some of the options for saving the files and searching for files, and the ever powerful command pallet, which has a lot of features in it that we're going to have to explore. That really make it easy for us at a single key stroke to open up files and do lots of different commands. And of course any editor needs to have really good file navigation. And the first place to start is understanding what kind of an editor is Visual Studio code. And it's hard, it really is just a file or folder base editor. It knows how to open up a single file, multiple files, or a folder. We don't need the have a project context, however if we do have a project context, such as a package JSON for Node project or a tsconfig JSON for our TypeScript project or any of these other kinds. VSCode lights up specific features for us. But even if it doesn't have one of those project types, no worries, because it's still a great editor for any kind of code. So we just saw the editor itself and here's a screen cap of that. Let's take a step back and look at what we have. Of course this got a menu bar and this is what it looks like if you've got a Mac. And if you've got a Windows one, it'll look very similar. But on the left hand side we've got the view bar and the view bar is four distinct icons at this time. And the first one's the explorer button, so we can look at all of our files. That's what shown here right now. The second one's a search button, so we can search our files throughout the entire folder inside of VSCode. The third one's git integration and the fourth one is a debugger. Now we're looking at those files in the explorer on the left hand side inside of a sidebar. The sidebar, itself, is where you're going to see those different view bar buttons that open up inside of the sidebar, using viewlets. In this case we see the work in the files and the folder structure. If we clicked on the search button, we'd see the search sidebar. On the right hand side, that's where the editors going to be, any file that we happen to open up will open up in the right hand side. We've also got this nice blue bar at the bottom, that's our status bar. Now on the bottom left we can see it says master, that's our git integration, it tells me what branch I'm looking at. And then there's the number of errors and warnings that happen to be in my project at the time. Now on the right hand side we can see what line and column number we're on and the last file we're in. The file format and then also the language, in this case JavaScript. And for good measure, the smiley face that you can click to actually send some feedback to the VSCode makers. But what's that big thing in the middle of the screen? That's the command pallet. And this allows us to open up files or warning windows or run tasks, get commands, go to specific lines in code, run the debugger, do all sorts of things right from the same place. We'll be using the command pallet extensively throughout this course. So let's go back into VSCode and look at some of these different options and see how they work as well as a few additional options.
-
Getting Familiar with Code
So let's take a look at the sample project called code play that came with the course. If we open that up by typing in code. inside the code play folder, we'll open up Visual Studio Code to that project. So this is a very simple Angular project, but the project's kind of irrelevant. We just wanted something to look at so we can explore Visual Studio Code. So first let's say we're looking for a file called dashboard, how will we do that? We could click on the search viewlet over here in the view bar and we can type in dashboard and hit the Enter key. And we find everything that's got dashboard in it. Now there's all sorts of advance search options you can choose, such as regular expressions and matching case. We can see down here all sorts of different things that are containing the word dashboard inside of it. Of course the very first viewlet is the explorer, which shows us the working files and the folder we're in. If I happen to open a file, let's say we'll go and open up this bower JSON file, you'll see the working file shows up over here, even if I close that file. And sometimes you end up with all those files and folders open, really deep, and you just want to hide them. Right in the bar here you can hit this button to collapse them all. The other buttons up here allow you to do things like refreshing the list or creating a new folder or a file, which you can also do right from right clicking inside of here. And of course we can drag and drop the move files around and copy and paste. Before we move on, one of the interesting things in here is notice that if I'm inside the working file and I start typing, let's say I type in here hello world, I know that's not valid, but that's okay. And I type up there, notice that this file doesn't show any icons to say whether it's been dirty or it's been saved or anything like that. That's because I'm using an option that's up here called auto save. It's in the file menu and it's been checked on, I checked that. Let me uncheck that for a moment now and let me type something else in here like hello world, goodbye. Now when I do that, notice I've got a little dot next to the left hand side of the work bower JSON. And it shows one has been unsaved. So if you want to automatically save your files as you're typing, you can just click the auto save, but if you've got certain tasks that run automatically and you don't want that to happen. You can actually uncheck that for your project up here. I'm going to put it back on, because I happen to like that. We're going to explore many of the options, there's so many more inside of Visual Studio Code that we can set up, in a later section. But that one's kind of important, so we hit that now. Next up, let's look at this button here. That's going to show us the viewlet for git repository. Now this particular project hasn't been set up in git yet, but I could, I could just click this button here, set up git, and automatically have a repository local. And then I can push that up to a remote somewhere else if I want to. We'll explore this a little bit more later too. And then this buttons for debugging. That opens up the different debugging features, such as looking at the variables, setting up watches, the call stack, breakpoints, all sorts of cool stuff we can do, as well as different debugging profiles that we can have. We'll explore how to configure debugging in a later section. So coming back over into our bower JSON, we see we've got all this code in here now let's say we had an error inside the code. For example, I forgot a comma. Notice that it tells me right away that it was expecting some kind of a closing brace. And also in the bottom left hand corner, you can see how many errors and warnings we have. If I click on that, you'll see that there's an expected closing brace up here. And if I highlight that it will show me where it is, right there in that file. So down in the left in the status bar, we've got our git repository, which is hasn't been initialized yet, we got our errors and our warnings. And we work our way to the right we can see what column we're actually on at this time. Now we can type in a column at the top, in the command pallet, if we type colon, let's say we type in 17. It'll actually highlight that line. If I change that to 19 it'll move down to that line. And yes it will scroll for you, so go to down like let's say 40, it goes to the bottom of the file. Let's fix our code up here and now moving right along to the right, we can see we've got our characters set, we've also got what kind of line sequence do we want to use. And then really important one over here is the language that we want to use. This is the mode. Notice it's detecting right now that I'm in a JSON file. Let's open up a JavaScript file and see what happens. Notice now it knows that it's JavaScript. And of course if we open up a markdown file we can see it knows that it's markdown as well. Well we can change that mode up here and so look all the different kinds of files it recognizes. Things like coffee script or Doccer files, Java, JavaScript, it also recognizes objective C. And this list is growing all the time. If you have feedback for the team you can click on the little smiley face in the right hand corner. So you can say how's my experience? You can tell them something about this, you could put your email address in, and either submit a bug or request a feature. Which is kind of cool right inside the tool. And I'm kind of working our way back up we start at the upper left, when to the bottom, across the right, and now let's go to the upper right. Of course there's always the x in here so you can close a particular file. But in some files there's context sensitive other buttons up here. Up here we can split an editor, so we can have two versions of a file and we can up two different files, so I can up that Gulp file on the right, the readme on the left. And then if I'd like, I can close the Gulp file, but what if I wanted to go ahead and look at preview mode of this markdown file? Well in this one, because it's note is markdown, I can see I've got two readme files and now I can hit this button over here on one of them we'll click on the right hand side. And I can change it and now we can see that there's the generator markdown. So code has recognized the markdown on the right hand side we can see the output of that. So based upon the file type you're in, you might see different buttons in the upper right hand corner. And finally we've got our menu items. Up in code you can always tell if you're looking for updates up here, you can set your preferences through here, either user based one for just me or for the entire workspace on my computer for all the things I'm doing on my computer. There's also keyboard shortcuts, which are really handy, especially if you're used to different editors. And then user snippets. We'll be exploring all these throughout this course. Now we've got the file window, which has the basic normal stuff, other than the auto save. We've got our edit window in here as well. And then under view we've got our command pallet, which is going to be Shift + Command + P on the Mac. This we're going to use extensively in here and we'll explore in just a moment. We can also look at our errors and warnings, that's the same thing as clicking on it in the bottom left hand corner of the status bar. Toggling full screen, pretty cool, so we can get rid of the menu bar on the top. And then the split editor, you can always do command/ to get that. And toggling the sidebar, that's kind of neat, so let's click on that and show you what happens. When we click there, you'll notice the sidebar just disappears entirely. And I can hit the keystroke to get back if I want to. But it's really great when you're trying to make more room inside of your editor. So let's go back up into here, we can also move the sidebar, watch what happens here. Now our sidebars on the right, so if you like to read the other way this works for you too and again you can collapse and expand it. So now here we move it back and let's say you don't like the dark editor, you can go down to the theme, there from themes you can go from the dark right over to the light. We can also go backwards and forwards in our file history that we've been looking at or the different working files. We can navigate the history, there we can see the different files in that history and we can go up and down those files to open up a different one. We can go right to a file, assemble it definition, or align. Definition being maybe a function definition a line of course is self-explanatory. And it simply can be something inside that specific file. Then, of course, we get the standard window and the help menus. Next up let's take a closer look at the command pallet.
-
Exploring the Command Palette
Now slip back over to the dark theme, because I happen to prefer that. And we'll close out the window we're looking at and explore how we can use the command pallet. Let's say all of our files are collapsed and we had no working files at this time, but we know there was a file in there called dashboard. Well here I get a command P on my Mac or I could go look in the menu up, Go to. So you go to file, so can see what that might be and the different operating systems like Linux or Windows. So I command P up there, I can type in the name of the file, like dashboard. And notice it's doing pattern matching as I start typing in dash. So I don't need to type in the full word. And then I can start looking for the file I wanted, let's say it was this dashboard controller. Now we're good to go. Instance access to that file. Well let's say I also wanted to open up a file called app.module. Well now I type that in and go to that module and you can see I have different files that are opening up. Now I could say I could type in here I'm having a good time, I type some different things, like hello. And let's go back into the dashboard controller. What I'm doing here is hitting command P twice. Let me show you that again, if I hit command P once, then hit it another time, it's actually going back in the history. So by hitting command P twice in a row, holding the command key, doing PP, I can go back to the previous file that I was in and just go through the different files in my history. So you can see that the commands pallets a nice quick way to navigate so you don't have to go all over the place looking through your explorer. Now let's say you're inside of an HTML file, we'll open up command P again and go to the index HTML and notice I've got this file down here called temp style CSS. If I put my cursor over that, sometimes it'll say, use command and a click to open that up. So I come over to the side of that command an option, because I'm on the Mac, it'll tell you where to go if you're on Windows as well. Now you can see that file over on the right hand side, that's pretty cool. But what about other kinds of things that I can do, beside going straight to a file? Well let's try command + Shift + P. Wait, what's that? This is like the main command pallet. You got the little caret up there. And if you hit the wrong key, no worries, watch what happens if you hit command P for the files and now I type in a caret, it turns into that pallet. They're all the same pallet, it's just I use a prefix character as the first character to tell you what kind of commands you're running. If there's nothing in there, that means it's going to show you, okay, we want to see a different file that's inside your folder. If you type in the question mark you can see all different kinds of commands that you can run. So here we can see the caret is to run a command, like maybe open the debugger. The bang is going to show the errors and warnings, same thing that happens when you click on the status bar in the lower left hand corner. The hash is going to be open a symbol inside of a file by its name. First you run git commands just by typing in git. Or we can hit in task, so if I type in git you can see I get check out or branch. If I have a task runner, which is there none right now set up, wait it found one in my file system, very cool. It sees I have a Gulp file in this project, so it will automatically detect those in some cases. So a task so that I can run a task that happens to be in that file. Let's go back and hit the question mark again, now we can see an open files and symbols by name, go to a line inside of a file or go to a symbol or a one by category. So where did all this come from again? No worries, go back up into the go to and you can see the different kinds of commands that you can open up up here. For me the one command I wish I remember, is command B, that's the one that'll open up the window like this and then from there I can type in the caret if I wanted to do something like I want to do configuration of debugging. So I can click on that. Maybe I want to change the language mode, so I can type in language like that. And that's the same thing I clicked when I clicked on the HTML or the JavaScript in the bottom right hand corner of the status bar. What if forgot how to go the themes? Up here I can type in theme. And now I can quickly just say, oh I can change my view to the dark theme or the light theme, just by clicking up inside my menu. So I can type that back in and go back to dark. Now let's go back into a file, like the dashboard controller. We'll go in there and type in dashboard controller. And this time let's walk around a little bit, we can see the code is in here and maybe we want to find a specific symbol, like let's say there's a lot of code in here and we couldn't find this get message count. So let's scroll back up to the top just so we pretend we didn't see that. Now let's hit the command P up there and remember that question mark that we hit to see what are the different characters? Well it says if I hit the @ sign I can go to a symbol, so let's try that. We'll delete out the question mark and we'll put in the @ symbol. Now notice it's showing me here I've got four symbols. The dashboard controller and as I scroll down you can see it highlights what it is. The activate function, get message count and get people. Now that's pretty cool, so we can go right to a specific symbol just by doing this. Well there was another kind in there too, go to symbol by category. Notice that's the @ sign with a colon. So I can do that with a colon and then if there were more than just functions there, like there we strings and other things, it would actually categorize them by functions and maybe strings or properties. And notice that it shows here that it's got this little thing to the right hand side of activate. This little split window, what happens if I click on that? Now we can see that I've got the same file open in two places, but it actually scrolled to the activate in one side and left it where it was in the other side.
-
Side by Side by Side Editing
And there's one feature I just love, and that's because I can edit side by side by side inside of code. Well let's take a look at what that means. Let's say I'm looking at the dashboard controller and I want to look at its spec files as well. And maybe I also want to take a look at the index HTML all at the same time. How can I do that? Well first I'm going to go ahead and remove from view the sidebar and I can do that up here with the sidebar to toggle it or I can use a keystroke. And then once I do that, I went about multiple panes, so command 1 is going to let me go to the first pane in the window. Command 2 is going to open up another one. Or I could just hit the command and the slash. So now I've got three of these panes and that's where it maxes out right now. And I think that's enough. But over here in the middle one, if I put my cursor in it that one I can now go ahead and navigate to a file, like the dashboard controller spec right there. And then I can go over into the third pane and I can open and navigate to another file, like index HTML. So now I've got three files open at the same time. Well maybe that gets a little hard and confusing to see, so let's say I wanted to close out the index HTML. Maybe I'm working in the spec at the time what I can do, is I can highlight the third pane and then hit command w or I can just do close file. So up here you can see that you can close a particular editor right there. So let's try that with the keystroke. Now I've got two panes. So let's go back to three for a moment and let's open up that index HTML again. And let's say I really did want to look at all of these, but I want to focus on one just for a moment, but keep the other two open. What I can do is drag this over to the left. So I drag the pane right here and I dragged it all the way to the left. What that did was it squished the first two file panes and left the third one wide open. Now watch as I put my cursor in the first one, because maybe you want to look at that. Soon as I do that, it basically uses an accordion to show me the most width I could get for that first pane and squish the other two. Same thing happens if I click in the middle one now. So I'm moving it all the way over to one side, you told code that you wanted this to act as an accordion, so you could actually look at one file with the most width and leave the other two kind off on the sides. You can also use a keyboard for this, so if I do command 1, you'll see that one comes into view. Command 2 and then command 3 and if I want to close any of those out as I go, let's just say I want to get back to the dashboard controller, I can command w to get out of the ones that I don't want. And I can bring back my sidebar with a command b. Don't worry if you didn't catch all those keystrokes, I'm going to give you a cheat sheet up in my blog, which I'll be linking to several times throughout the course. And you can always go check them out at the code website.
-
Important Keyboard Shortcuts
So as you can see, you can be very efficient and effective and quite fast at coding inside of Visual Studio Code. So about those keystrokes. The ones you really need to remember are the command pallets itself, which is command + Shift + P. If you can get there, you can type in any command you want. Or just basic command + P, which does your file navigation. So if you remember anything, remember those two. And of course you can always just type in question mark there, and in that case you're going to see all the different kinds of things that you can type inside of the command pallet. So if you don't remember all those keystrokes, don't worry so much, you can just run the commands right from the command pallet or go to the menus too. And if you want to check out all the different kinds of things you can do from the keyboard, there's an updated list all the time at codevisualstudio.com/docs/customization. That's right at the source of truth from the Visual Studio Code themselves. And I've also got a couple of blog posts in the series about Visual Studio Code, which show you how to get started with these. And some of my favorite keystrokes are in there too. So now we've got Visual Studio Code downloaded and installed and setup on our machines, we can launch them from the command line. Use a whole slew of different keystrokes that we learned, take advantage of the command pallet, the different panes in the windows that are in there. And really navigate through our files very quickly. Up next we're going to learn about all the different kind of refactoring and debugging and all sorts of great features that Visual Studio Code has to keep you productive.
-
Getting Ready for Node or ASP.NET 5
Using Node and ASP.NET 5
Now that we have a great sense of the layout of code, let's take a step back and look at what we need to do to run some of the different technologies in code, such as Node or ASP.NET5. Visual Studio Code is code agnostic, pun intended. It works in multiple languages, so we're going to be using code in this course, because we need to make sure that we can learn how to use the tool. So we're going to need something, right? So we're going to show Node and ASP.NET and TypeScripts and JavaScript, for example, but we're not going to be reliant upon those in the actual tool. In other words, and to keep it short, you can use any language that is supported by code such as these ones here. Which are also found up on the link that you can see here on the bottom. So whether you're using Ruby or Markdown or Objective-C or TypeScript or JavaScript or even Doccer, you can use that with code. And to find out more on the updated list of the language and the features they support, check at the link here at the bottom of the page. So let's go through a quick primer of how you can get up to use Node and ASP.NET. First you can use this on Mac OSX or Windows or even Linux. We're going to grab Node and NPM and you can use either Brew or Chocolatey to do this. Brew is for OS X and Chocolatey is for Windows they're basic just tools that make it a lot easier to get Node. So how do you do this? Well let's take a look at OS X first, you're going to want to install Homebrew or Brew for short, from this link here. And to do that, you'll say brew install node and that's it. And for Windows you're going to use a counterpart to Homebrew called Chocolatey, which I guess it tastes better, hmmm who knows. Anyway you go get Chocolatey from here and you just say choco install nodejs and then choco install nodejs.install. And then we're good to go. Once we have those, you can look at this link here to see how do you actually install Node on Windows. And I've got extensive details in this blog post to help you along in actually installing Node. Let's say you're on OS X, well you can elevate the need to run pseudo on OS X as well, which is basically a super user, like an admin. And this basically allows you to not have to type pseudo before all your commands and you can learn more about that at this link here. Are these required for this course? No, absolutely not. But if you want to follow along exactly with what I'm doing, this will help. Well what about ASP.NET5? Well if you want to learn more about that, you want to check out this link at their main homepage. They have great instructions there for getting ready on Mac OS X or getting ready on Windows. For example, I've also made some of my own little Nodes on getting setup with OS X at the ASP.NET5 right here. The simple instructions are we use brew again, we're going to tap ASP.NET and their DNX core. Then we'll update brew and we're going to add a single line to our bash profile, that's this echo source line. And then we'll install the .NET virtual machine and then we're going to go ahead and upgrade it. Once we have all those, ASP.NET is ready to go. So I mentioned this thing NPM. If you're familiar with it, well great, it's basically a package manager for Node. If not, well I just told you what it was. So here we are installing packages like NuGet or Maven or Gradle that's the same kind of thing as NPM. Just a different technology, we use NPM for JavaScript. And we use commands like npm install --g my package name. What kind of things might we install? Well Gulp, because we're going to use task running. To make it easier for us to do things like changing Less into CSS. And NPM again this is package manager we're going to use to get all these guys. Bower, the pretty little bird here, he's going to be for client packages. So Bower and NPM are very similar, mostly NPM is used for our server side packages and Node and Bower for client. And then we'll use Yeoman, this little guy here who looks awfully friendly, to help us generate a new project with either Node and Angular or maybe with ASP.NET 5. That's basically a file new project. So why do we need NPM? Because we're going to be installing some of these guys to help run ASP.NET and Node for the samples. Code doesn't require these, I'm just showing you these because it'll be easier for you to follow along. So what could you do? NPM install -- g means we're going to install it globally and we're going to say install yo, that's yeoman the friendly little guy from the previous slide. And then gulp, that's going to help with our task running, so we'll show you how that works inside of Visual Studio Code. Then we'll use bower, which will help us install client side packages. TypeScripts, because that's going to be the compiler when we actually show TypeScript support and it's obvious to do your code. And tsd, which will help us get typings files. Don't worry if you don't know what that word is, I will explain more about that a little later, but it's going to help the tooling experience. And hey, that's why we're here, right? So the second command is also installing more packages, these two specifically are generators that I chose just to show examples in the course. The first one, generator hottowel is going to help us create an Angular project using JavaScript. So we'll get a little Node a little Angular a little JavaScript then we can follow along and show the features in Visual Studio Code. The second one's generator ASP.NET, which as its title says, is creating an ASP.NET project that we'll be using. These two will help us show off most of the features that we need to see. And again, -g means a global install, and these generators are just going to help us get moving along. And TypeScript's really just there for the tooling. But hey if you want to learn a lot more about JavaScript and Gulp and all the things I just mentioned, I've got a course that kind of helps you go through all of this. So if you'd like to get more details, by all means head over there and check it out at this link, but again these aren't required to actually use Visual Studio Code, because again, you can just use the multitude of languages. So now that we have a sense for how to get going with code, let's go ahead and jump back into the tooling.
-
Refactoring
Code Refactorings
We spent a ton of time reading our own code and then refactoring it. Making changes to it to make it better. This is one of the places that Visual Studio Code really shines. So what is refactoring? Well of course we go through this process of we code, we write our code, we do our thing, and then we find that code, and then we change that code. Sounds super simple right? But as we know as developers, that's not always so easy. We're always looking for ways to make things faster, more efficient, more productive. Because a lot of times I've got code ideas in my head and I can't get them down fast enough using the keyboard. So Visual Studio Code helps address that problem with many types of refactorings. In this module we'll look at many of these, including bracket matching and selections there's many different ways we can select things with the mouse and with the cursor. I personally like to keep my hands on the keyboard and keep moving faster. And, of course, there's things like auto complete and Intellisense that help us fill in code faster so we don't have to worry about how long a variable is or a function name, for example. And who wants to remember the syntax of parameters and functions, so hinting is really great. And I don't know about you, but typing HTML can be monotonous, so I like to use Emmet, which is a great way to use little shortcuts to type our HTML super fast. So I'll show you how to do that too with HTML and CSS, but sometimes you can't use tools like Emmet that let you type in really easy standard HTML syntax, because that doesn't change a lot. Maybe you've got syntax that's your own or a company standard you use. Or maybe you're just creating like an Angular controller or a service. That's where custom snippets can really help you, so I'll show you how you can use and create a custom snippet and I'll give you some out-of-the-box that I've created for Angular. The bottom line is, Visual Studio Code makes it easy for you to make your life easier by using those. And it's got the basic stuff, like going to a definition or a symbol or looking those up by name. It's go gutter indicators, for things like git or errors and warnings. It's got peeking into your code so you can look at how a functions actually written without actually going to that file. You can actually dive in a little bit more just by looking and hovering over variables and functions. You can rename them, of course. And it's got these great little lightbulbs that pop up called code actions that make it easier to refactor. For example, the code actions will basically let the VSCode take a guess at what it thinks you should be doing to refactor this. And, of course, taking a look at errors and warnings and going to the next error or warning. And there are many more of these that'll help you be productive and none of them are hard on their own, they're actually quite easy to use. But there's so many of them that let's go ahead and show you how to use them in VSCode and I think you'll see it will really help you become much more productive.
-
Bracket Matching and Emmet
Let's start by taking a look at some of the basic selection and finding and navigating features inside of a file. So let's go ahead and open up an HTML file, I'll open up this dashboard HTML. I'm hitting command B to get rid of the sidebar. And what if you want to find where this div closes? Now I can see it's the end of this line, but while I'm on this opening brace, notice that the closing brace is also highlighted. But we have bracket matching too, so I can hit command + Shift and then the right square bracket and notice it went over to the end brace there. If I hit that same keystroke again, command + Shift then right bracket, it goes back over. And if you're trying to find this keystroke, if we go inside of the command + Shift + P, which brings up our command pallet, we can type in here, well look for bracket matching. So I type in bracket and we can see that that's actually the Shift + Command and then right square bracket. And we can do it that way. Obviously the command pallet is not the way you'd want to navigate that, but it's a great way to find the keyboard shortcuts. Visual Studio Code has a port for Emmet out-of-the-box too, which gives us more HTML features. So let's say we wanted to just type div and then inside of that div we wanted to have a UL. And then we want that UL to have, let's say, five LIs. We could do LI right there and how do you do five of those, we can do *5. Now if I hit Tab, it's going to automatically generate all that HTML. And notice it's kind of got a cursor there in the first spot, so let's see what that happens there. I can type I first, hit Tab, and go to second, and then just keep typing like this. As long as I know how to spell I'm good to go. Now you can use that and hit Escape to get out and to also create things like table or anything else that's more complex. So notice below we have div of the class, if we wanted to create that, we can say div and then we can .container, boom. And then we've got div class with container. And if you want to learn more about the Emmet syntax you can check out this link here at docs.emmet.io. And there's a cheat sheet right on that page where you can learn all about Emmet. If you've typed in any HTML, make sure you clean it up as you go.
-
Selecting and Cursors
One of my favorite features of Visual Studio Code, is what I call the multi cursor or multiple cursors. You can use that in any kind of file, but for grins let's get rid of the code you put in here. Now let's go over and look at a JavaScript file. I'm going to go ahead and look at the dashboard controller in my project and you can see this in your code play. Now to sell multi cursors, there's a couple ways you can use this. Let's say there's a situation where I want to highlight every instance of this VM variable. Just by putting my cursor inside of it, I can see it turns gray. Now I can hit command F2 and every VM inside of the entire file is now highlighted with the blinking cursor. Don't believe me, well let's check it out. We can type something in like hellow right at the end of it or we can delete that and now we have nothing there, we can type in John or we can Ctrl + Z and get back to what we wanted. But maybe we didn't want every single occurrence of that word to be there. Maybe we just wanted the ones with a dot after it. So let's hit Escape to get out of that mode. Now let's go ahead and highlight vm., once instance of what we're looking for. And think of this like a find and replace, but we're going to have a little more control over it. So I'm going to hit Shift + Command and L and you're going to see now it's only fine in the places where they had vm.. Notice the instance on line 11 is not highlighted right here because there's no dot after it. So again, maybe I don't want to delete what's there instead of just typing over it like this right we're John, opps, maybe we want to rename the VM something else. So now I hit the left arrow and I still have my cursor in all those places and I can type in VM and just put 1, 2, 3 here, whatever else I wanted there. It's a great way to rename certain instances of variables or code blocks. Then you can still do your Ctrl + Z to get out of there. And then we hit Escape to make the cursor to go away. If I use Alt and Click, so I'm doing Alt and holding it down the whole time and just clicking anywhere I want. And you can see I'm just dropping cursors all over the place. So now I put my cursors in there and I can say, hellow that's a lot. And again I can just Ctrl + Z and escape out of there. You can also use the option command of the down arrow, this might be useful if you're right on top of each other, like maybe I want to stick a word right after vm here. I can do option and then command and then down arrow and boom, boom, and you can see I can draw cursors there. I can also do the up arrow if I wanted to and go up. So now I can type things in here like hellow. But perhaps my favorite one is using the command D or progressive multi cursor selection. So sometimes I want to find all the instances of something, like maybe vm., but I want to look at them as I go because I'm not quite sure what I'm going to find along the way. If I hit command D on the selection, it'll go select the next one and the next one and the next one. Now I'm going to do it to the next on here and maybe I didn't actually want to highlight the one on line 31. Holding down the command key still I can hit command K and it's going to skip this one now if I hit command K then command D. Notice it skipped over line 31. So it just approved that, let's replace the vm, in this case, with the papa. And notice it did it everywhere that I had the selection, other than line 31, because it skipped it. So that was command D or command D plus command K to skip it. And again we can Ctrl + Z, let's undo that, and Escape to get out. And if you want to find some of these keystrokes, you can go ahead and open the command pallet and type in what they are, like select. And that's the add selection to find next match. Or I call it the progressive multi cursor.
-
Powerful Multi Cursors
So what else could we do with this? Let's show you something a little more powerful. So let's say I'm inside my bower JSON file and somebody wanted to be able to type in a bower install command with all of my dependencies, without having this bower JSON. For example, the command line someone wants to type bower install jQuery angular angular sanitize and so on and so on. Well one way I could get to that pretty easily is if I could just strip out what I need out of this file. How could I do that? Well first I know I don't want the quotes there and I don't want the versions, so what I could do is look for everything's that got the quote colon. Not in the entire file, but I want to use a progressive multi cursor and I'm going to go down to find each one of these. Now I don't necessarily want to delete those, but I want to go back arrow once and then I'm going to use a Shift command and then end arrow to get to the end of the line. And then I'm going to delete those. Now I'm going to do the command to the front of the line, move the arrow to the right once, and then delete again and backspace. Now I'm going to highlight that space there get rid of those, and to go down one arrow, this is kind of cool, hit the backspace and a spacebar. Now I hit the Escape key, go to the front, and I can type in bower install ---save-dev if I wanted to or ---save, whatever. And now I can take that command, copy it, and maybe I open up another editor, let's just go ahead and open a new file here. And we'll say new file. And we can paste that in there. And you can see the command that we just pulled out of there. So you can see that using the multiple cursors and the progressive cursor could be a really easy way to take a file and edit it down really easily. Let's close this file here, we'll go back to the file we're in, and of course I'm going to undo what I just had. And we'll go back into a code file. Maybe, for one last example, we wanted to say everywhere we see a function I want to make sure that after that function I've got a space before this bar. So one way to do that is to find everything that says function (Space), go get my progressive's everywhere in the file. And then make sure that I've got a space right there. Or maybe I only want it where there's anonymous functions. So let's go find a first anonymous function that we have, which is right here. So then I can say get the function, the space, and the first parenthesis I have. Go find them all and then I can take this here and say, maybe get rid of that space. And then you can see them down here on line 30 and then again on like 37. So it's an easy way to start doing refactoring these are some pretty simple things you can do, but you can imagine how powerful it can be once you learn these keystrokes, to really refactor superfast.
-
JSON and CSS Intellisense
Code has some pretty awesome Intellisense out-of-the-box, especially if the language service knows the possible completion. So let's take a look at some of these things. We'll start off with a bower file, right here inside of JSON. Let's say that I wanted to know what other possible options I could have for my bower file. If I come in here and I hit Ctrl + Space you're going to see a list of all of the different schema options I can stick in here. So the code recognizes this is JSON and it knows the schema, because the bower file is called bower.json. So let's say I want to type in the authors for this list, I could type that in here and I can start typing in the names. And I can type in John. Well now it's also telling me what's wrong. Notice down here it says it sees a duplicate in there for me. So I can get rid of that one there, but what about a little bit smarter completions, like let's say I know there's some touch library out there called hammer, but I'm not sure if it's hammer.js or hammer or hammerhead or who knows. Well in here I can start typing in ham and then I can hit Ctrl and Space and notice it's going to look on the fly, inside of bower, to see what are those different options. Oh there we see it, hammer.js. So I can type that guy in and then I can put the version in over on the right hand side. So it's not only smart for the schema, but also smart for what I'm looking for when it's a bower file. This also works for package JSON too, let's take a quick look. So inside of here let's say I wanted to put in a package that happened to be an NPM and let's say I'm typing in Angular again. So I can type in angl and we can see it pulls up Angular and then I can get all the versions that I want to get too. If I actually delete the star and do Ctrl + Space, I'm going to see the possible versions that are out there. And it tells me a little bit about the tilde or the caret or the exact match. So that's pretty cool, but what say you didn't know what kind of file schema it had. So let's create a new kind of file here and we'll call it jsconfig.json. Now this file is actually one that's going to help you configure your JSON for your JavaScript project. So inside of here I don't really know what schema I have, so as soon as I hit that curly brace there now I can do a Ctrl + Space and it shows me only really two options I've got, compiler options. So I'll just select that with the tab and then here I can o Ctrl + Space again and see there's different kinds of things. Now this file, I happen to know will help me compile to a specific target of JavaScript, so it knows inside of Visual Studio Code or whatever editor I'm in, what kind of language I'm going to. In other words, I want to use ES6 or ES5, go ahead and let me do that as the target type. So it helped me fill in that schema right out-of-the-box, which is pretty darn cool. But that's just JSON and we'll leave that file there, because that's going to help us later. Let's go take a look at one of our CSS files. So we're inside of styles CSS and we'll just create a new style up here called our super awesome style. And as I type that in and I hit those spaces, now I can do Ctrl + Space and I can see all the different kinds of styles I can use. Notice this is also putting vendor prefix extensions there. Let's say I wanted to put in there border color. I start typing in border and I can, let's say, border color down there. And now when I hit Ctrl + Space it's telling me here's the possible options that I could be using. Now these aren't all of them obviously, but I could type in a color and it's also showing me the color right on the left hand side. And I can also come in here and say alright I don't want that, I want to go ahead and put this color in there and get kind of a violet. This also works for Lasso or for HTML or SAS or C# or TypeScript out-of-the-box too. We'll take a look at TypeScript in more detail in a later module, but next let's take a look at JavaScript.
-
JavaScript Intellisense
Now let's say we're inside of a JavaScript file, like dashboard controller here. It could be any JavaScript file and this one's got Angular code in it. Notice Angular is underlined, well I wanted to know what Angular is, but it's just thinking this it's any. Well any is a keyword in TypeScript, that's the type in TypeScript to say hey this is any particular type. I'm not using TypeScript, so it can't figure out in the JavaScript what this is. Long story short, we can help code very easily. Because then we'll know things like this $q what that is, because that's part of Angular as well. And if I go to files like I've got this thing called a data service in here and it's got $http, right now it just thinks it any. So how can we help it out? One way is right on top of Angular we can hit this little lightbulb, this is a code action. And it gives us a suggestion, we can rename it, mark it as global, or we can say reference this DTS file. And I'm going to do that or a quick moment. Notice it puts this file up at the top right now. And now Angular's no longer underscored and it tells me, oh it knows exactly what that thing is. Well how did that help me? So now when I start typing code in here for our things like $http notice it knows what that is and it knows what kind of methods are on it, like get. And then it tells me all the information about the parameters that I can pass in. That's pretty darn cool. I can also use this on Angular up top. So we had Angular for our .module maybe you wanted to add a controller. So now it knows there's a controller and it sees the different signatures here. And I can toggle through them, 1, 2, and 3 different signatures I can use and pass into a controller. This is really important by the way, because it's giving me all this Intellisense and auto complete in JavaScript by using TypeScript typings file. I'm not writing TypeScript. So I you don't want to use TypeScript and you're allergic to it, no worries, you don't have to touch it. It actually just helps you in the design time develop time experience. But maybe you don't want to have this little line at the top of your file, I know I don't. So I'm going to go over here and let's remove that file that I created. And it's going to pull out that angular.d.ts file that we added. And we'll go back here into the state of, I don't have any Intellisense.
-
JavaScript Intellisense with Typings
The next step is we're actually going to open up a file that I've given to you, it's called tsd.txt. Inside of here we can see, we've got a command called tsd query --r-o-a and then we're going to install a bunch of files. What the heck is this? This is basically a way a command using tsd and if you install this in module 3, you'll have this in your machine. If not go back and do that now. And when you run this, it's actually going to go out to this library called definitely typed. It's a GitHub repository where it contains all the typings, basically all of the types and interfaces and everything about the signatures of these libraries. In other words, if I run this command it's going to run out and get all that information provided to VSCode, it's a onetime thing, it's not part of your code base, it just stays in this folder called typings. So you don't need to worry about checking it in if you don't want to, you can get ignore it. And it gives VSCode all the power that you need. So we can run that command or we can start up by just doing ______ to show you exactly how it works. So first, let's go ahead and just grab that first part of the syntax, that's going to be tsd query, just like that. And I'm going to go over to a command prompt. So inside a terminal I'm going to type that command and then I'm going to type in Angular and I'm going to put --s, the --s is to save it out. Now these different parameters are a is for action, -s is to save it to a file, so it remembers these commands. That's why I knew the ones that I have in here, because I had these in a different project. The --o is overriding in case it's already there and the --r is going to do basically a recursive search inside of all the references. So it's for references. Meaning if Angular has so many references it'll grab it. So let's go ahead and run that. Now it should run out to the internet, grab those, notice it installed Angular and jQuery. So I come back over into my project now I go over and in get to see what happened. I have this tsd JSON file, which it added, it's just a JSON file tracking what I actually added through that command. Then I have this reference file it adds for me. So it's a single file on your project and then you can see the two different typings files, here's the Angular one, which defines all the different types it has and then the jQuery one. So I can come back over here and we'll close those working files. Now let's go back into my data service and notice I don't have the green squiggly under Angular nor do I have the references at the top, but I do have my typings right here. So again I can come in here and type in things .service and I'm good to go and my HTTP and my queue and all that, it knows all about these guys. So anything I'm using will actually get pulled in and I just did that in this one case for Angular, but I also got jQuery because it was a reference. But let's say I wanted to get all of those. Now let's go back to that file I gave you and let's copy that whole thing. Don't worry if already ran the first command, because the --o is going to allow us to overwrite. Now I'm just going to paste that in there and hit Enter, it should go off to the Internet, grab them all, and write them. And you can see that was pretty darn quick. Now looking at the get changes you can see all those files that got pulled in under a typings folder. So again you're going to get ignore that file you want, all you really need is the tst JSON so it remembers how to do that. And we'll close that file and go look for one of those instances. So I believe inside of my app we have a core constants file in here. And it's actually referencing toaster right there. So we can see that says it's of type toaster. So if I just started typing down here and said toaster. you can see there's methods on there like, oh toast up an error. And I can put a message in there like, hello! And it's actually giving me all that Intellisense right out-of-the-box now, because that's coming from that file that I just pulled in. So it's pretty easy to see how you can get Intellisense in these different files, like controllers or services in Angular, by using the tsd, which comes from NPM, which adds these typings. Why is this working so great? Because I'm inside of VSCode, which has TypeScript baked under the covers which helps you look into these different typings for a great tooling experience. So again, just because it's real important, pointing out that I'm writing regular old ES5 JavaScript and I'm getting better design time help in my editor by using these typings files through VSCode. So how's this going to help me? I'm going to write less bugs, because now I'm going to know if I've got a problem before I ever run my code.
-
User Snippets
There's some pretty cool snippets built into Visual Studio Code, for example, let's say I wanted to use a function, we can create one down here. I could type fun for function and you can take that function statement right there. If I hit Tab I'm going to get an automatic snippet there where I can type in the name of foo. Hit Tab again it goes to parameters, I can type in like age, maybe name, hit Tab again and notice it goes to the empty lines. So I can tell the snippet where the end of the line is. So then I can hit Escape and get out of there and then finally I can also put in comment if I want to where I just type in the standard JavaScript comment syntax and it'll automatically create them for me. But inside of the snippet, I mean that's nice that they come with some out-of-the-box ones. Wouldn't it be nice if I could have some Angular ones to kind of give me the format of things that I want. For example, if I create a new file I want to create an Angular controller, I don't know if you're like me, but I forget the syntax of things all the time and I usually end up copying and pasting. So, what do you do? I don't want to have to learn to type in Angular controller and well was the first thing or did I did a modular, or I forgot the iffy out there. So what I've done is I've created a few custom snippets that I could use. So when you're inside of a file type, let's say I create john.js real quick. And inside of there I can type in, it recognizes it's JavaScript, ng, because I created some custom snippets. Now I can say controller. And it's going to automatically generate the basics of that controller snippet for me. So now I can type in things like, oh my modules name is app.mymode, hit the Tab here, and my controllers name is going to be customer. Now notice it filled in all the places where customer needs to go and let's say the dependency in this is going to be $q. And then I hit Tab and it goes to an empty line, I can hit Escape and I'm out of there. Well how do you get custom snippets or how to do make your own? If we go up into the code menu up here, we can see that we've got preferences. And then down here we've got user snippets. So we click on that we can see there's different languages. All the snippets are stored in a file on your computer based upon the language that they're used for. So you can have snippets for batch or for Docker or for JavaScript, the file I was just doing. Or Java or iOS or the Objective-C, or you can just do it for TypeScript. So let's go ahead and type in JavaScript and you can see there's already some in my file. Yours may be empty, that's because I've typed these in already. And if you want to find more about these specific Angular ones, you can go to my Angular style guide at this URL right here, which is jpapa.me/ngsytles. You can grab those right from there but these particular ones here, what you do is you type in the name of the snippet you want. So that's what going to show up in the window. Let's take advantage of the sidebar to see how these work in action. So I'm going to hit command 2, so I can open up another sidebar pane. And I'm going to go ahead and get rid of the sidebar that I had. Now I can see I got the JavaScript JSON on the right and I've got on the left. Well let's go ahead and open up a file on one side, like dashboard controller or let's go to the empty we had, like john js. I'll clear out that file. Now if I type in ng controller you can see here that that's what's showing up, is Angular 1 controller right there. You can see that is the name. So now you can see the module that's highlighted it's actually matching up with the variable on the left hand side on line 9. And then you can see the variables are all using this dollar sign curly brace and then the name of the variable. That's the syntax that we do. Now why do we have all these different things inside of this array? So here is the name of the snippet, here is the prefix that I'm going to use, like ng controller. The body is actually the snippet itself and then the description is what's on line 25. Now if you forget what these are, no big deal, I can create a new one here, let's call this the john snippet. And if I do that and put my comma there, now remember I can get my Intellisense by doing Ctrl + Space. So now I can type in the description and I can say this is just a temporary snip. And I can go alright what else do I need? Oh I definitely need a prefix something to type, so they actually show the snippet. So we'll just call this john. And then let's go ahead and we'll put in the body. Now the body is going to be an array and the array is going to be every line by line of that snippet. So if we flip back down to the Angular controller one, we can see we've got function and then the comma says, okay that's the first line that's the end of it. Now put this string on the second line. This string in the third, it's an empty space, and then this one on the fourth. Notice the /t, the /t is a tab, that's why I'm indenting over here on the right hand side. So let's go ahead and try out kind of how some of this works. Inside my body we'll do a very simple snippet, we'll just put a comment in here that says hello world john. Just like that, no variables, no nothing. Now if I come over here, will it work? Well if I type in john we see temp snip is showing up, that's the name and the description of my snippet. Now the body should work as I hit Tab. And there we go. Now here's a little type, if those don't ever work and it doesn't register right away, if you go to your command pallet and you type in reload window. Remember Visual Studio Code uses a browser. So based upon electron, we can just refresh the whole environment. So if I just do that real quick if things weren't working, now they should be working. In my case they were working anyway, but that's just a nice little debugging type. So if we come back up here now and we can add other things. You can say hello world john and down here we can put a space. And maybe now we're going to create a function. So let's create a function and we'll call it john again, just like that. And we want to do a second line of the function and now I want to tab into it. So I'm going to do my /t and let's say inside of that function I'm just going to do return the number 1. And then I'll close out my function. So now I want to not tab, I actually just want to close out the curly brace. So if I flip back over to the other side and I type in john I have exactly what I asked for. Well having a function name john on a snippet isn't going to help so much, but maybe I could create a function that's like, my function, like that. And I could call this snippet down here my fun. Well down here let's not make it john anymore, let's replace that with a variable. So we'll replace that in there with the name. And then let's get rid of the value and let's have that return a value like my value. So now flipping back over to the other side, we'll delete that guy out. I'll type in my fun and now you can see name is highlighted so I can type in here that's foo and the value could be 34. So as you can see, snippets are really easy to create and then when you want to move through different variables you can repeat those, as you've seen here with the controller. We see the word controller right there repeated and again repeated there and again repeated down here, because I used those multiple times, sometimes in the same snippet. There's one last thing that's kind of cool about the snippets, that I like, and that's, let's say, you didn't really know what you want inside that function. So let's get rid of this return value. And let's just do this, $0. Now the dollar sign's a variable and zero is just telling it as a placeholder to go here. So I come back over, I can type in my fun and then I can type the name in, I can say alright that's going to be foo. And when I hit Tab I'm going to end on the line that I want it to be. So now somebody can type in the code that they want and say alright return whatever. So you can make your own snippets anyway you like, here we've got a bunch of Angular ones that you have that you can download off of my site for the jpapa.me/ngstyles. You can grab these for factories, services, directives, I threw in a bunch of these and I use these all the time, because I don't like memorizing syntax. It also provides a great deal of consistency and efficiency in your code. So what if you're not doing JavaScript? Well if we flip back up into the code menu up here we can see preferences user snippets, we can also see we can create other ones down here. We could create one for CSS if we wanted to. Notice they give you one out-of-the-box to kind of give you an idea and a comment of how to do this. I've also got some that I've created that you can get off my style guide for TypeSript2 if you want to take a look at those. So you type in TypeScript, you can take a look. Here we can see the same ones written for Angular controller using TypeScript. This is an area I expect to grow quite a bit with community contributions, so definitely take advantage of this, anything you need to put in here, absolutely do so. It's made my life a lot easier and I hope that these particular ones I'm getting to you will make your life easier.
-
Sharing Snippets
And the last thing it's really important to point out about the snippets is notice where they're stored, Users/john/Library/Application Support/Code/User/snippets. You can always see that path, so I you wanted to share these, you could absolutely do so you could either open them up, copy and paste, or you could just go out to that folder. Because under that folder is where you're going to see all the different files of your different types. So they'll be a file for TypeScript ones, JavaScript ones, C#, whatever you're doing. So it's a great way you can share these throughout the entire team.
-
Go to Definition, Find References, and Peek
Let's take a look at some of the ways you can navigate around a file. Let's open up a JavaScript file that has a few internal references, for example in here I've got this data service variable, which I'm referencing as a parameter of the function on line 10. So what if I didn't know it was up there on line 10? There's a couple of things I could do. First I can hover over this guy and notice it's telling me it just knows that it's a parameter and that it's of type any. It doesn't know what type it is, but at least I'm getting some information. Just like if I hover over %q, it's telling me it's a parameter and that one it knows is part of Angular ng.IQService. So it's actually got an interface and a type that I can play with. So hovering gives us a little bit of information that we need, but maybe I want to know where is this data service? Well we can use the F12 crew, the F12 crew is by hitting the F12 key on the cursor here on data service. If I hit F12, bam it's going to jump right up to line 10 and show me where that definition is. So F12 is going to go directly to the definition. Well let's pop back down here again and let's say that I wanted to use that, but now I just want to just peek at where that definition might be. So if I hold the option key down and then I hit F12 on line 30 here on the data service. And we'll scroll up a little and I'll do option F12. Now I'm peeking into the code, so now I don't have to disrupt where my cursor is because that can be kind of jarring, especially in a large file or going across files. I can see that data service is peeking into, oh like right there on line 10, that's where the data service is. So F12 to go to the definition and option F12 to peek. Well what if I want to know where all the places that I use this in this file are? Now I can use Shift + F12 so in that case I'm also peeking, but notice the right hand side, I can actually see the different occurrences of where data services use. And I can go over here and I can click on those and say, alright where's the first one where's the second one. Now it's kind of cool, let's say I wanted to change code, I can actually use this peek window and I can type right inside of it and say ha ha I'm inside the peek window and I wrote you code. I'll hit Escape here and when I do notice the code is still there. So the peek window is an interactive window that you can use to help not disrupt your flow inside your code.
-
References in TypeScript
When VSCode detects a language like TypeScript or C#, we get a little bit more power right out-of-the-box. So let's take a look at an example of a TypeScript application using Angular and you can get this code right out of the source folder. Or you can grab it right from my GitHub repo at GitHub.com/johnpapa and then the name of the project, hot towel angular is our TypeScript. But the projects not so important as it is what's in it. So if we look in here we can see a bunch of TypeScript files, like app module ts and under dashboard we can see dashboard controller ts. Let's take a look at him. Under here let's just simply just hover over a couple of these guys. Like we know that we have this class called dashboard controller and notice it tells us what it is, but we also can see it implements an interface, which is right above. And then down here we've got the data service variable which is telling us what type it is. And then what type that is, is an interface, which is pointing to another file. So one thing I can do is I can just while I'm hovering over this file, hold the command key down. Notice I'm getting a little bit of peak at what the interface looks like without doing anything else. All I'm doing is holding the command key down. Now I can hover over core or app as well and I can see what those things are. And notice it becomes like a hyperlink. So if I click on that, as you might imagine, I'm going to go right to that file, right to that particular place. Now to go back, I'll hit command P twice, that's a quick way to get back. Now if I'm hovering over here and I want to open up to the side, one thing I can do is hold the option key down and click. So now I go to that place, but I don't lose my place in the file it was on, on the left. So I'm using those side by side panels to do that. And I can flip back and forth between these panels, I can go in a number 2, and then hit command w, close them out. And I'm back inside the dashboard. So we saw just by hovering right here I can see a little bit of a peek inside there with the command key. What if I want a little bit more? Now I can use the p command and I can go and do an option F12. So here I hit option F12 and I still get my peek right into that file where I need the IDataService. And again I can type right inside of here if I want too. Now I can hit Escape to get right out of there. So we went to the definition with the F12 or just by clicking it with a hyperlink, F12 brings us right there as well. We can also do the go to reference with Shift F12. In this case we're going to see multiple files on the left hand side. So here we can see that we've got data service ts, that's the interface and then the implementation of it. And then dashboard is using it in one place. So we can click through those and kind of see where are those particular files being used. Let's take a look at something that used throughout more files, like this logger. So this logger, if I hover over him, do command, you'll see it goes to a logger class. Well loggings used in a lot of places, so let's check him out. Instead of using the keyboard, let's use the mouse. In this case I'm going to right click and you can see I've got peek, go to definition, final references, so you don't have to memorize all those F12 keys, like I have. But you can just right click and you can see them right here. So now I can say, file the references of logger. Notice when I do that, I'm getting several files on the right hand side. So we can see it's using many different places. So I'll hit Escape get out of there. So let's say we want to go over and see the definition of logger. Let's do that. Here I am inside the logger and you can see he's got methods like log and error. So let's figure out who is using the actual interface or our logger. Let's get on top of him, we'll right click, we'll do final references, and again we now we can see the I interface is used in just two places here, inside this particular file. But now if we go look at the export of the file itself, that's the class, we can do final references and again we see all those different files. So we can keep peeking in all the files. This is a great way to kind of scan your project and I often like to do this. I get rid of that view, kind of make all the real-estate I can whenever I want to look through all the references, because it's just a lot easier to see all these different things. And as you might imagine, inside of the file and TypeScripts, you're also getting cross file Intellisense. So in here where I'm using the data service to call get message count, notice data service, I click on here, it's highlighting on line 16, showing it's being imported in, that's another file. And it's got a method called guess message count and it's actually telling me what type that is. It's going to return a promise that contains a number, which is why I'm getting back my data and it's actually being set to a message count, which happens to be a number defaulted as zero. Let's say I wanted to take advantage of that Intellisense. I type I the data service, I can see the different properties. This one here is getting message count. And let's say I forgot the parameters, it's going to tell me, okay there are none. And maybe I skipped and forgot that it's actually returning a promise. So in this case let me return and set it into the message count. So I say, this message count equals this data service. Right away it's going tell me, look this guy is an integer, a number in this case, and it's being tried to being set from a promise. That's not going to work. Now if this is plain old JavaScript, you wouldn't get any messages or any errors, because it doesn't know, but because this is TypeScript and VSCode detects that, it's actually going to tell us, in this case, that hey that's a problem. So we can see lots of good ways that VSCode can help us make our code much cleaner. And if you ever forget those keystrokes, no worries, you can right click or you can come back up to your command pallet and then type in something like references to find all references. Or you forget how to peek, you can type in peek, but in general, most of those are associated with F12 and some other keystroke combo.
-
Finding and Renaming Symbols
Let's say you wanted to search first in symbols in your project. Now I'm in the TypeScript project, so if I'm in there on like C# or one of those languages that has a lot of static types in it, I can search for my symbols. And to do that, let's say I didn't know the keystroke, I could open up my command pallet and I could type in just question mark to show, look go to symbol at the bottom or go to symbol by category. Let's try go to symbol, which actually happens to be command + Shift + O. So if I type that in, now I can see all the different symbols in this project. Notice that is the namespace, there's my interface and it highlights them for you as you're going through. So if you wanted to find something in a large file, like where is that get message count, I could type in get message count right here. And you're seeing now that you've got it in the interface, right there. And it's also inside this function. But what if we wanted to categorize those? Notice it says symbols 20 on the right hand side now. If I stick a colon there, now it's breaking these out by classes, interfaces, methods, modules, properties, anything it can find in there. So at sometimes it makes it a little bit easier to find what you're looking for. Well what else can we do with symbols? Let's take a look at a file that uses another file. So here we have a dashboard controller and this guy is using the data service, right here on line 33. Let's open up a second pane, I'm going to do a Command 2 to open up a side by side panel. And over here I'm going to hit the command P and go find my data service ts. Now the data service is what this guys using. So let's say I wanted to rename get message count to something else. What I could do is hit F2, for rename get message count, and then I hit the Enter key. And notice what happens. Get foo, which is right here, and I'll highlight that with a command D to show you progressively, only one place in this file. And then over here there's a get foo and I'll highlight that progressively. Two places in this file. So it updated every place that it found get foo, both where I did it in dashboard controller and in the file that actually had that function. Well let's try from the other side. So now over here let's say I wanted to rename get foo. So inside of the data service, I'm going to rename get foo back to get message count. I hit Enter and it changed it in all those places again. And if I want to see what those references are, I could right click, or use the Shift F12, and I can see all the places that's being used. So you can easily rename things and refactor them across multiple files as long as your references are intact.
-
Errors and Formatting
Let's have some fun by screwing up our code a little bit. I'm going to go ahead and just de-indent all this and I'm going to indent all that. And let's say somebody in your team typed all that code in like that, because it's never you, right? So inside of here, we can format our code. I'm inside of the TypeScript file if I want to know what that keystroke is, I can open up my command pallet. And I can type in format, I see it's Shift and then option and F on the Mac. Or I can just hit Enter here. And it'll instantly format the code for whatever type of file that it happens to be in using your user preferences. So that's pretty cool. We can do that again real quick we could just de-indent a lot of this and then indent some crazy stuff all over the place. And well it's not going to fix that error, but let's go ahead and do that. Now we hit Shift + Option + F and boom we're back in business. Alright, well that's not screwing up our code enough, so let's screw it up just a little worse here. Let's get rid of a colon here and there. That's not good, right? And down here let's go ahead and well set the return value to the wrong kind of thing. So in this case instead of get back data, we'll say alright the message count's going to be a string that says hello. And that's not going to be the right type, because that's supposed to be a number. So it's telling me I've got a problem, but notice also down here in the left, it says I got 17 issues. Well now I've got all these underlines telling me what's going on. But what I could do is I could actually use my command pallet to help me out. So in the command pallet I can open this up and I remember if I hit the question mark I can try to remind myself what these different commands are. And notice I hit the bang, it's how errors or warnings right there. So let's try that real quick. So I can do the command pallet and do the bang, and now it's showing me all these errors. And it'll actually let me go right to one of them, like right there. So how do you tell what that error actually means though? Once you're in your file, if you hit the F8 key, now I can see exactly what's going on. It's showing me here it thinks that a semicolon's expected because I declared a variable without a type, but actually what I want to do is put the colon in there. But if I keep hitting F8, it's going to show me every error that I've got, it can't find string. And notice it's going progressively through all the errors that I have inside my file. And it'll do this for the errors and the warnings, depending upon what you've got in your app. So right now I know that message count was wrong, we'll get that back to data. And now let's go back through and it's down to 16 errors, we can see we've got some other errors coming through. Now it's all being stemmed from missing this one semicolon, so once I stick that guy in there I should be back in business, right? Well nope, because I still have one more error. In this case get people is actually missing it's type as well. So I put his colon back in and notice that there's no more errors, no more underlines, and I don't have a problem down here in the bottom left. Now another way you get to that window, assuming we had an issue, let's put one up there, there that semicolon. I can hit Command + Shift + M and it will also show me that same pane. So I can start scrolling through there. And you can actually search for the errors too. So I could look for anything that says anything that's looking for an expected signature. Or again, I can go through the F8s. So with these, VSCode can help you remove some of the errors in your app.
-
Quick Line Movement and Editing
Code will also let you do some neat nifty tricks like moving lines up or down. So sometimes you might not want, for example, get people to be on top of get message count, because maybe you want it below it. So you can use a keystroke to move it down. And that key command is to hold the option and the down arrow and it just moves it down one line. Obviously then I got to fix the comma, not a big deal there, and we're good to go. So this could be kind of handy if you wanted to move a function up or down as well. Maybe you wanted your success to be below the fail. I can highlight that and now I can move it down until it's in the spot that I want it in, right there. So if I want to duplicate a line, I can also do that by holding Shift and then Option and the down arrow. And it's going to copy that line right below it. And it's telling me I can't have two of the name same name, so I could just change that. I can also use Command X to delete a line. For when I copy a line above something, like I'm over get people, I can do Shift + Option and then the up arrow, it'll copy above it and leave the cursor in the line above. There's a lot of cool nifty commands that you can check out. And in the next module we'll learn more about key bindings and how you can make your own keyboard short cuts.
-
Refactoring Recap
So, there's a ton of Refactorings in Visual Studio code. Did you catch them all? No worries if you don't remember all the keystrokes, because remember, you can always go to the command pallet and check them out and go search for them. Some of my favorites were the multi-cursor, but I also really liked the peek where you can just hover over a particular variable, use a keystroke, and then I can see in another file, for example, what the logger is doing here, as is referenced from the dashboard controller. I also really like the find all references where I can go look at the logger and say, "Who's using this guy?" And over on the right-hand side, I can see all the files using it and actually explore the code and edit it right in place. And one of my personal favorites are the Snippets, the custom ones that you can write. So you can write Snippets of your own. And if you ever have any bugs in your code whatsoever, it's kind of nice to be able to have a really easy way to navigate through them. So, the command pallet that helps you do that using the bang or the command + shift + m; then we can just toggle through them with F8. And all these features make it much easier and make it much more efficient to refactor your code.
-
Themes, Preferences, and Keyboard Shortcuts
Themes, Preferences, and Keybindings
One of the great things about editors is they really allow you to customize how you're using them. And Visual Studio Code lets you do this with themes and preferences and keyboard short cuts. This module will take a look at three of these and see I can customize them to suit you. We'll start things off by taking a look at the themes that you get out-of-the-box. There's a light theme and then there's a dark theme. One there's also a high contrast theme when you're working with Windows. One of the most commonly voted up user voice items or Visual Studio Code I the ability to create custom themes. The product team left a comment saying that that's something we're looking seriously into and should be coming in the very near future. And that's good news. So let's take a look at how you can use these and the rest of the features to customize your Visual Studio Code experience.
-
Theme
Changing themes is pretty darn easy, we can do that from the menu by going to View and then Theme and then select Dark theme, for example, Or we can hit the Command + Shift + P, pop up to the top, and I can see Dark, it goes to the dark theme, which I was on, or I type in light and it'll flip over to the light theme. You can also assign custom keystrokes, so you can flip between the light and dark themes. For example, I've assigned Ctrl + Shift + D to go to the dark theme and Ctrl + Shift + L to go to the light theme. Those don't come out-of-the-box though, but you can assign any keystroke you like. And in the future the product team is hinting that they're going to allow staff customized themes too.
-
Adjusting Preferences
So a whole bunch of ways that we can use user preferences, but let's start by taking a look at an example of how it might help us. So let's say we're inside of some code file and by accident we put a bunch of spaces at the end of the line. Well I can see that they're there, if I go back up to that line and kind of hit the back arrow you know I can see that I'm not really ending at the curly brace like I thought I was. So let's go look at the user preferences. I'm going to hit Command + , that's preferences in the Mac or if you wanted to, you could come up in here under Code Preferences, and then you'll see that you got in there. And in this let's take a look, we have the left hand side and a right hand side. The left hand side are the default preferences or settings that we have. The right hand side are the preferences based upon my users workstation. So on this computer, these are the ones that will override the ones on the left. I can't edit this file on the left, watch, noting's happening as I'm typing. And on the right hand side I can type what I want. So one of the options I could put in here for the whitespace is to say, alright I want to be able to show the whitespace. And maybe I don't know what that setting is though. So I start typing in white and notice it shows me there's a render whitespace option. Now we want to change that to true, so we could just type true or I can do Command + Shift + , and that will change the value to true. So here, we just type in , there, now let's flip back to the file we were on, we'll go back and do Command + 1 to go to the false settings and then we'll do Command + P and we'll do that three times to get back to the controller. And now you can see we've got dots after the news right there. We see those little dots that I'm highlighting. So how do we get rid of those? We'll flip back over, do Command + 2 to get the second pane, and you might have noticed there was also another option of when I typed in white and that's trimTrailingWhiteSpace. So we can put that in there and then we can toggle that to be true as well. And now let's flip back to the first pane I'm going to come into here, and when we type something else it'll actually auto save and when it auto saves it'll get rid of those little dots that you see in the end of line 12. So let's take a look at this, let me just go up to line 8 here and I'm just going to add in a comment at the end of the line. And when it auto saves, notice the end of line 14 no longer has those dots anymore. So what options do I prefer? I actually don't like to see the render whitespace true, so I get rid of that because I trust that the trim trailing whitespace is just going to handle everything for me and I also happen to set auto save on. Which you can see up here under the file name. These are just two of the settings that you can use. Let's explore some other popular ones that I like.
-
Favorite Preferences
Let's take a look at some of my favorite settings that I like to override. So again we go hit Command + , Command + B to hide the sidebar, and in here let's tinker with one first called lineHeight just to show you the power of what you can do. Now I like to leave this at 0, but what happens if set it to like 5? Warning, you may not want to try this, looks what happens here. 5's not so good, so I'll hit Ctrl + Z or Command + Z out of that. But if I do have a little bit of problem where I want to space up lines more. I can set this to like 20 for example. And notice I get a little more spacing in my lines. So it shows you a little bit of what we can do on this. I also like to have format on type set to true, so it automatically tries to format my line for my spacing. Speaking of spacing, what about tab size? That's a good one. Very controversial, right, everybody likes to set their own tab size, so you can use auto by default or you can get rid of that and then you can put in here a value like 2. So now we've got 2 for out tabs or a 4, which is another popular one. Or if you just want to go crazy you can do like 3, but who would do that right? So instead we can just leave that at whatever preference we happen to want, I like 4. Another good one is the editor wrapping column, so the best way to show this is to actually show it. By 0 basically we're going to turn on wrapping, but we could also say let's put this at like 20 just to show you an example. Now it means it's going to wrap the code at 20 characters. Not so great. Now the default on this is 300, so we can set that 300 and it goes all the way across I happen to like setting it at 120, because that's a good width I can use. So it'll wrap once it gets there and allows me to do side by side panes and see most of what I'm looking at. Notice over here on the line 21, I have to scroll a little bit to see that okay, I have a little further to go. IT goes all the way out to character 120, but I don't have to go all the way to line 300 there. So I can change that to whatever value I want, definitely do something custom for you. There's a whole bunch of other options too, one of which is files to exclude. And if you're not sure what that does, one way to find that is you can hover it and it'll tell you we're going to configure the glob patterns, basically the file matching patterns, for the excluded files and folders. So we're not going to be using those files and folder in all of our searches and what not. So here we have the .get, .DS_Store for the Mac and then here I'm saying optionally we can put a condition in here to say, find all the files that begin with js and hide those when the base name of that file matches basename.ts. Basically, if I've got a TypeScript file and a compile JavaScript file, I want to hide the compile JavaScript file. So you can actually use conditions in these cases too and that's pretty powerful. Now everybody has a favorite font as well, so you can do all that kind of stuff up here and type in font, you can see there's a font family. Let's say for some reason you wanted to use the impact font, you could do that right here. And it'll immediately change since the file changes. And probably not such a great font for typing in code. Or we can just get rid of that entirely, we can put it back to default just by deleting that line. Of course this is only going to apply to fonts that are on you system. So if I typed in a font family that happened to be like popup, now there is no popup font that I'm aware of, so it just goes to false. But what if you want font size? Well that's a good one, a lot of people like to have a specific size open when they do this. So you can come up here and you can type in a font size, like 14. And these are some of my favorite settings that I like to override.
-
Finding Preferences by Keybindings
Hey John, how do I know what other options I have in my preferences? I'm glad you asked. So we can go into our default settings and you can scroll through here, there's a whole bunch of, that's kind of boring. Or we can hit Command + Shift + L and up top we can look for the symbols. So now we can start typing in those letters right here and we can see what are the default settings for auto closing brackets, we'll set those to true. So we see that they're all organized by the type of preference that they are. So these are the editor preferences and you can scroll through those and highlight's them below. You can also type in something like TypeScript, and you'll see there's a couple TypeScript settings that you can set. As you might guess, there's also CSS, we can click on all of those settings. You can also take a look at the JavaScript settings too. There's a whole bunch of these that are baked in out-of-the-box, even JSON settings. And if you type in something like script, you'll see all the ones with script in it, or just Java, it does partial matching as well. And we can put a colon up in the front right after that and you'll see it breaks it apart by the different data types. The ones on top are another Boolean settings for JavaScript and the ones on the bottom are the string settings. Now this is a great way to find out what are the defaults and then you can go over on the other side and you can override those to anything you like.
-
Overriding Preferences
So we've taken a look at the different preferences that you can use in the VSCode. In fact we've seen two types of the three that you can use. We've seen the default settings and we've also seen the user settings. But there's also a workspace setting too. So what's the difference? The default's ones are the ones that comes with code, they're the ones you can't change that we looked that are on the left hand side of the pane. And then there's the user preferences that we set and those are on the right hand side of the pane, the one we could actually override. now those are user based, because they're set on your computer in your user folder, which is different based on which OS you're in. And that works for all instances of code that you have running in that machine. So this is really handy for when you want to have the same settings across all of your code instances, like maybe always on the same font size. And the last kind is a workspace, which is basically saved inside the folder of the project you're in. So it'll create a setting.json file for those preferences, which get carried along with that particular project. So you could actually push these into source control, so whoever uses that project or that code, can then pull that out with the code. The first two types are for your machine basically, the defaults for code. And then a default for your user and then the last type is the kind that gets carried along with the code. And these override each other in sequence, so the user will override default and workspace will override user and default. So when do you use a workspace, well it'll create that settings JSON file and for now it stores in this workspace.settings folder. Although I kind of get an idea they might change that later on actually where it's stored, but it'll be somewhere inside your project, as of the preview version. And this will always override your user preferences and of course your default preferences. Let's take a quick look at that.
-
Workspace Preferences
Back in Visual Studio Code now, let's take a look at those preferences. We go under Code and then Preferences and notice there's user settings, those are the ones we got when we looked at the Command + ,. That showed us the defaults and then the user based ones. Well let's click on Workspace. So here's workspace and on the left again we can see the defaults that are over here and again we can't type in those. And then I can see my workspace settings, which I have none of for this particular project. But it also created this file over here called settings.json. So it's going to store these with the code, so I can push this up into get if I wanted to. And again, I get the same features over here, I can start typing something in and say only for this particular project I really want to use tab size 2 maybe. Because the people on this project happen to like that. And therefore I can override the default and use that. There's a message you might want to cross and I want to show it to you, because it might concern you when you see it, but it's not so bad. Basically, when you have the different workspace and then the user settings open, it's going to warn you just so you know what you're doing. For example here, these are the .settings file, I know that's local my project. But what if I hit the Command + , again? Now it's telling me, ah oh, you're opening up the workspace settings and the user settings at the same time. So it says the current open folder has the workspace ones, that's the one for my project. And then, right her I've got the user settings as well. So if I hit Command + B you're going to see over here, in my working files, I've got this JSON file right here, which is my users JSON, you can tell by where it's located. And then I've got this one down here called my settings JSON which is the ones from my workspace and that's this file down here actually in my code. So is that a problem? No not at all, we just need to make sure we keep them straight. so we've got the user settings right here and then we've got the ones that are for my workspace right down there, which actually creates a file in my folder. So there's a nice flexible structure where you get default values and then you can override those for your computer or for that particular project. And I expect this list of preferences will continue to grow over time.
-
Keybindings
In addition to the different kinds of user preferences that we can set, there's a whole bunch of key bindings that we can use that come out-of-the-box with Visual Studio Code. And we can also set up our own custom bindings. We can check out this link here where the code team has placed a bunch of them up on their website. Some of my favorites are the ones that let you do things like formatting the code. And if you forget the keystrokes, you can just go into the command pallet and it'll show you these when you search for format or format code. I also happen to like the different F12 commands that they have, such as the peek, which we looked at earlier, the show all references so I can see everything that's being used. And then the F12 where it actually goes to the definition of the thing that I'm on. And based upon the context of that, whether it's like CSS or TypeScript or C# or JavaScript, it'll actually go to the definition of that particular object. And again, Command + P it comes in very handy to go to a specific file where you type in a name or to go back in the history of the recent files you looked at. And of course there's the Command + 1, I'll cheat a little here, it's more than one keystroke, Command +1, Command + 2, or Command + 3 to go to the different panels that are inside of code. Breaking the command slash to open a new one, all the way up to three of them. And I happen to like the full screen keystroke, which gives me a little bit more real estate and gets rid of the menus. But we can also define our own key bindings and these are done through setting up rules. And the rules have three simple properties. We have to tell it the keys that we're going to use to press to actually make this key binding work. And optionally we can tell when this is going to happen, so you might only want this keystroke to matter when it's in debug mode, for example. Or only when you happen to be inside of the work bench, basically inside of editing a file. And finally, what's the command you want to execute? And we'll do this by editing our key bindings inside of code, it's basically just a JSON file. And we'll take a look at how to do that. But for a quick preview, you might want to do something like this create a key binding to change the light theme. I set one up here, where I set the key to be Ctrl + Shift + L and then I didn't care when it was going to happen, I wanted it to happen everywhere. So I omitted the when. Anytime I press that three keystroke combination, I'm actually going to go workbench.action.changeToLightTheme. And then I'll flip it over to the light theme for me. Now as you might imagine, when out-of-the-box, might look something like this, with F5. F5 key will automatically run or debug so here we see the command for that one is to debug.play, but what context to that is going to be when it's in debug mode. So F5 might behave differently in a different context. When you're setting up custom bindings it's really important to understand there is certain excepted modifiers for these. And they're different based on the operating system. For example, in OSX we can uses Ctrl, Shift, or Alt or the Command key, plus some other keystroke combination. In Windows we have similar ones, but there is no Command key, there's a Windows key. And then in Linux we also have the special meta key. So it's pretty common for us to use one or more of these together in combination with a letter or number or some other key to actually create basically a cord so we can open up and call some command. So let's take a look at how we can do this to be more effective inside of code.
-
Defining Custom Keybindings
So let's take a stab at creating our own custom key binding. Inside of code, going to top menu, go to Preferences, and Keyboard short cuts. And it will hide the sidebar. On the left we have all the default keystrokes and on the right we have the ones we can override. So if I open that up here we can see here's all the ones we've got, and if I scroll to the bottom of that file, hit Command and then down arrow. Now you'll notice something interesting down here, there's a bunch that our commented out. Now I didn't put these in here and you can't delete them, it's a read only file. These are extra ones that you can define that do not have something defined by default. For example, we might want to assign a keystroke to work back action files, toggle, auto save. Remember that nice little file, auto save check box we have up here. So let's to that, just to try things out. So we'll grab that syntax right there and now remember that little tip I showed you earlier, if you pull this panel all the way to the right. And now if I hit Command + 2 it'll actually snap to that same size that the first pane had. It's a great way to toggle back and forth. Now I have a few commands in here already, but let's set up this new one. We'll use a keystroke, now what keystroke do we want to do to actually set this up? We'll leave that blank for a moment and I'll stick in Command, notice it auto completes for me. And then I'll just paste in the command that I wanted, toggling auto save. So for that key, you might not want to run into the same one that you had before, we can take a stab at one first and we'll see how we can check to see if it's duplicated. So we toggle auto save, why don't we try something like Ctrl + Shift + T, awesome. So now to try that we can go hit Ctrl + Shift and T, because it's auto saving already. And when I do that, let's go back up to the menu and now auto save you see is off. So let's try it again, we'll hit Ctrl + Shift and T and we'll go back up and we can see it's checked on. Now we want to be careful not to override something else, so let's go back into this other pane and let's scroll to the top. That'll be Command + Up arrow. Now we could scroll through all these lines, remember there are 391, that's a lot of reading though. I want to check out Ctrl + Shift + T, what I could do is hit Ctrl + Shift and L. And then I can use the symbols to look for it. And I can look for Ctrl + Shift + T. Notice there's a couple that relate to tab, that's okay, they're not conflicting. So I seem to be in the clear. And that can be really handy to help us find out keystrokes. So let's go ahead and make this a little bit bigger, so we can see all the commands. Now hit Command + Shift + O and I'm going to look for, what is the Shift + Command + P? And notice I found two things, the first one is workbench action show commands. That's the one that shows the command pallet with the caret. If I go down this will call a different command when it's in quick open. So you can see how you can use the when context to override certain key bindings. This is also a great way to discover new commands and key bindings. As you can tell I like to use the keyboard, so Command + Shift + O, let's go ahead and look at the Command + 1 for a moment. Notice here you can see focus first editor, we've seen that already, it'll either focus it or open it up. Command + 2 is right below that, it'll open the second editor and Command + 3, but there's also a Command + 0 and that will focus on the sidebar. That's kind of cool. So you can actually explore these keystrokes to see all the different kind of commands you can do. It's just another way you can do that. You remember earlier we used the command pallet, we can also type things in here to find out okay what can we do? Perhaps we want to type in view the folks in the sidebar. So by looking inside of the key bindings in this file, we can search through all those key bindings that we have and we can also define our own key bindings over on the right hand side and notice that's also stored per user on your computer.
-
Customization
Oh the wonderful things that you can do with Visual Studio Code preferences too. Okay, that's a bad rhyme, but we did learn this chapter that we can look at a lot of different kinds of customization. So we can customize our themes from dark to light. And we can also customize our preferences like the font families, font size, wrapping, trimming whitespace, all sorts of cool stuff. And those can be done by my preferences from my particular machine. Or I can actually create a project specific file in a settings JSON file. And then I can push that u into my source control, so other people on my team can share it too. And if you're trying to figure out what key bindings there are, you can use the command pallet or you can explore the key bindings by opening up the keyboard shortcuts and then looking through the by symbol. And finally we saw how we could create custom key bindings of our own for things that aren't mapped or you could actually override ones that are mapped. This makes it easier for you if you're used to another editor and you want to come to Visual Studio Code and override the ones that you want. And the whole thing's based on JSON, so it's really easy to customize Visual Studio Code however you like.
-
Language Features
Language Features in Code
There is some pretty awesome language features in Visual Studio Code. Of course your mileage may vary based upon which language is important to you. So in this module we'll take a look at the kinds of language features that you have. And at the time of this course, there's basically three categories, what I call the basics up top, where you get the syntax coloring and bracket matching and stuff that you kind of just come to expect from any kind of editor for the basic languages. If it's got these, at least it recognizes what these languages are, right? So some examples of those in code are going to be like Ruby or Visual Basic or C++. Now there's a second level, which I kind of call, you know, you adding some intelligent help. For these we get things like CSS and HTMLs and JavaScript, specifically like ES5 and JSON files Less or Sass. In addition, just recognizing that the language exists and that you get some basic coloring and matching, you also get Intellisense or Linting or Outlining or some other features as well. You also get some basic navigation. Finally we kind of get the richest experience, which right now is C# and TypeScript. So what makes this rickets, because these guys happen to be able to take advantage of their compilers, like the TypeScript compiler or Roslyn for C#. So it can find all the references and do refactoring and basically jump through hoops for us. Now over time you're going to see more and more languages appear in the basics level and then kind of some of them will migrate up to the second and third levels as well. So let's take a look at a few of these from each category, so you can see what they have to offer.
-
HTML
Let's start by taking a look at HTML. Earlier we saw how we use Emmet in here so let's take a quick recap of that. We could do a div, which has a UL and maybe that one has four LIs inside of it. And then we hit Tab so Emmet lets us type this code really fast, so we can do what we want inside of here. Hit Escape to get out of there. But okay, this isn't indented properly and maybe we had a mess, you know, as you type HTML sometimes, I don't know about you, but sometimes things get out of whack. So how do you make that look better? Well, one way to do that is we can use the format code. So we open the command pallet and we can see when we type in format it's going to be Shift and then the option or Alt key and the F. And that formats it nice and easy. Alright, but let's say we didn't actually want that code and instead we wanted to type something in like Angular code. So down here I've got this NG repeat, but let's say I didn't know all of the syntax. So, instead let me go type something new up here. And we'll type another div in. And then inside of that div, let's say we wanted to create a UL again. This time I'll type a UL by itself and now I want to type in ng -, now I can't remember if it's loop or for or what it is. Now I can start seeing in here, well there's no for, there's form, I start typing in rep and I can see repeat, nice and easy. So it's giving me Intellisense on the most basic of Angular attributes inside of the HTML. And this is great because as popular as Angular is, it makes it nice and easy to see that we can get some Angular attributes right inside the HTML, and nice declarative attributes. And it also kind of signifies that if there's another popular framework, maybe those will also be added into code soon too.
-
CSS and Less
When we jump into CSS, we get some pretty cool things. For example, when we hover over .button in a class it's going to show us that this class will apply to any element that has a class of button. That's pretty basic, but you can also use it to figure out, well what's this going to apply to like navbar *, maybe you've never seen star before. In that case we'll show you that that'll apply to any element that has a class in navbar, who has a child element of any kind, that's what the star stands for. So we can see what these things do or perhaps the input type of radio. So when you get to complex styles it makes it nice and easy. We also get our basic syntax coloring, of course, and we get go to symbol. So we can type in our Command + Shift + O, we go up to our symbols, and we can type in a symbol like navbar. Which is kind of nice, so we can see everything that begins with navbar there, but maybe you wanted to find something navbar who has a child with a class. So I can do space., now I'm seeing everything that starts with navbar that has a class after it. Maybe I want a class with a button. And now once I do that I narrow it down and then I can highlight over them and notice that the line numbers are changing as I'm scrolling through those two. The first one happens to be in a media query, the max of the 979 and the second one with a different media query. Let's go back to the top. Let's add some other things to the select. Maybe we want to do select, we want to have other things like a background color. Notice we're getting Intellisense here and it describes a little bit about what that thing does. The color used for ______ background. And then once we do that we can type in a color and notice as I'm typing it, it gives me a little bit of preview to see, okay there's the color that I may want to choose. And you get this kind of Intellisense with all these property types. So I can type in something like a transition, maybe a transition duration. And if I hit Ctrl + Space I'm going to get a little bit of a hint here at kind of what's it looking for, maybe in milliseconds or seconds. So I could choose milliseconds there, maybe type something in like 50. Well let's take a look how we can use Emmet inside of CSS. And for this I'll make a faker class. Now when I normally type in like TA, maybe I'm looking for text aligned, because that's the Emmet command to do it. But notice table layout comes up first. If I just hit Tab here, it's going to select table layout because I had to select it. But if I hit TA and hit the Escape, I can go back to Emmet mode and now I can hit Tab and look at me text align for left. If I want to go up and down to these values I can hit the Command + Shift comma, kind of scrolls through those different values or Command + Shift + ., or the period. And I get out of that mode. I can also set things like margins with Emmet, so I can do like M: let's say 20. Now if I hit Tab I get a margin of 20 pixels. There's some other commands too, like border width and we can set that in here. And then we can set that up, we can set font size, which is fz, I like that, that's like fz. Or if we wanted to set it all at once, we could do fz: and then the value after it. So Emmet lets you put values after the colon. And you want that font size to be, I don't know, 14 ems? And some properties allow multiple values, so let's try something out with that. You do bd, hit the Escape to get out of the Intellisense, now we're going to choose border. Well that's great, but what I if you wanted to set, you know, 1 pixel and we want solid. And then maybe we want it to be some color like, I don't know, we'll choose 34, 34, 34. So we could choose something like that and type it all out or we could take advantage of Emmet. So now we do bd and we could type in plus. Now hit Tab and it'll actually fill in all those I's for us, which is awesome because if you're anything like me, you can never remember exactly which values go here. And then we could adjust the values if we wanted to and we're good to go. Now let's say you wanted to do a transition, whoa wait a minute. Transitions get a little crazy because there's multiple different vendor prefixes inside of CSS. So one way you could do that is type them all in, for webkit and Mozilla, Microsoft, Opera, hoof that gets crazy quick. So instead, we can type in --transition, hit the Escape key then hit Tab and look, it actually fills in all three and puts a multiple cursor in there so you can actually type in what you want to type. Alright that's pretty neat. But does that work with other things? Sure does. Maybe you want to try a background image? Well that Emmet keystroke we can do LG and then we can do a right in there. Let's put a color in there too, we'll do 444 and we'll make a percentage of 5%. And then we'll put another color over here and then we're done, we hit Tab. And look at that, look how fast I typed all those background images with those particular colors and opacities. So there's a whole bunch of things we can do with CSS. Alright, so we've got this wonderful class here and we could hover over it again and see where it's going to apply. I don't know what that's going to do for us with all those crazy styles, so we'll get rid of that particular one right now. But let's go find something with a percentage, because that's kind of cool too. Inside of percentage, like at the width, maybe we didn't want 97, when you hover that, you can do your Shift + Command then comma, they'll actually go up and down by whole marks. And if you only highlight one number, you can see what happens there. If you highlight both numbers, it actually does the whole number like this. But what if you're doing something like less, well let's go look at less file that happens to be in the project. And again it's in the code play project. And here, right at the top, and if you want to scroll you can do that or you can hit Command and then up arrow. We can see some variables, very simple ones to show us the colors. Well maybe on top of that color we want to right click or we could just say you know what, find all those references. And we can see every place that the color light blue is used. And you can scroll through there and again we can edit these right in place. You can also double click on it and go right to that particular location. Or we can right click here and say go to the definition or hit F12 and it's going to go right back up to the top. So as you can see there's quite a few really cool things built in with CSS, Emmet, and Less.
-
JSON
Now let's take a look at JSON and what we get with that. So we've already seen things like the bower JSON file and how inside of here we can hover over properties and we get a description. Well where's that coming from? That's all coming from schema information that we can store. So if we go back into our Preferences by hitting Command + , and we can take a look through here and see where's that in there. So at first let's look for bower, just kind of scroll through. And we can see down here there's a JSON schema section, so one was to search of course, we can also use our Command + Shift + O. We could have typed in JSON and saw all the schemas right there. Once there we can see tha's actually looking up the schema information at this link. Now we can click on this link by holding Command and then just clicking on it. And then we can see it right here. That's the schema information. So if you've got schema stored somewhere else or you can put it somewhere, you can actually create your own schemas by adding to this section right there. So we just extend these in your settings. Okay, but what else do we get? If we go back and look at the package JSON, that's our npm files, we can find everything with toas and then Command + Space and we can look it up and say okay I'd like toaster. And we could look up version numbers as well that happens to match this. We can take tilda or exact match even. And what's really nice is inside a lot of these JSON files, maybe ones you don't frequent as much, unlike bower JSON or maybe package JSON maybe you're using something like the JSON config JSON. Inside to there you might be like, well that's relatively new, what is that? If I hit Comma after there and do the Ctrl + Space, I can see all the different options that I have, like files. Well that's kind of cool, I can see the other options by hitting Ctrl + Space up here. Well that's nice I can type in module and it actually fills in the different values. Then I can use the Command + Shift + , and I can scroll through the different values that are there. And let's say you make a typo, like module, maybe I typed in commonjs like this. It'll actually tell me if I've got a syntax error. Or maybe I typed in something wrong like i typed in 12, it'll show me the datatype is incorrect and I can hover over that. I can also then hit the F8 key and it's going to show me the next error in the system. So that's just a warning saying that's an accepted value and it shows me what the right values are based upon the schema. There's quite a bit that we can do just using JSON.
-
Markdown
I spend a lot of time on GitHub, in fact I use readme files and markdown files quite a bit to document what I'm doing. So it's really nice to have a good markdown editor. So if I want to go find a readme file inside of Visual Studio Code I can type all the syntax and sometimes it's nice to see what it looks like. So the way I like to work here is I'll get Command + 2, so I can open up the second pane, hit Command + B to make the sidebar go away. And while I'm still on Command 2 with the focus you can see a blinking cursor there. And I'll hit Command + Shift + V. And that gives me a preview. And I'll go back to Command 1 and I'm inside of my editor over here and I can type live, I can say Hello world. And as soon as that saves you can see hello world showed up on the right hand side. Well that's pretty neat. So as I type my markdown I can preview it on the right hand side. And if I want to make that go away, of course I can go back to Command 2, to the other pane, and Command + W, we can closeout. Well what if you just want to see what it looks like? Another option with the mouse, you can go up here to the right hand corner and you can click on this icon right there and we'll see the preview. It's the same thing as hitting Command + Shift + V, which will toggle you back into your editing mode. But really that's not all, there's a pretty cool feature here too. Let's say you didn't like the markdown one that they have, so let's open this back up again and we'll go ahead and preview it, but we don't want to see the preview looking like it does on the right. You may want to use our own CSS for markdown. Ah ha there's a way to do that now. Let's go back in to the Preferences, right here, and first let's search for our markdown. So we can do Command + Shift + O and we'll search for markdown. Notice there's a markdown styles and right now it's set to an array of nothing. Well if I had a CSS style for some markdown, I could go ahead and preview it. Just to show you how different this could be for you, well we could have our own markdown style. So let's do that here. I'm going to hit Command + End to open up a new file for a moment. And in this new file I'm going to type in some CSS. Well we've got a file right in our hard drives here that came with the code for this, it's called markdown style CSS. Well one thing we could do is you can drag it over here into VSCode and I'm going to highlight it and copy it. Come out of there, we'll go back to our untitled file and we'll paste it in. We'll save it and when we save that let's go ahead and just name it mdsytles.css. Cool. So now we should be able to see that file right in the root. So let's go back to our Preferences and inside of our Preferences we can come back over into our right hand side for our user base. Now we can search in here for markdown again. Not showing up, so it's not in there and overriding it. We can type in markdown and we're going to get Intellisense. So we can type that in and then we can say, alright well we know that this is going to be mdstyles.css. And that should match, make sure we don't forget our comma, it should match what we have over here on the left called mdstyles. Once we do that, let's close out those windows on the other side let's go back into the readme file. Let's open the second pane and go into the view and bam, now we have a completely different look for our markdown files. So you can point these to something online on the internet, and you can use them progressively or you can look at one locally here and on your local machine too.
-
C# and ASP.NET
Now let's jump inside of some C# and ASP.NET. So we have this project called ASPPLAY and if we type in code. at the terminal or you can just open code directly and navigate to the folder, we can see a project here. Now the first thing I want you to notice is that we've got this main folder called ASPPLAY and then there's a project file underneath it called web application simple. So we'll close the window on the right just to make it a little easier. When we've got these two folders, well maybe you want to make sure that we know which one is actually the active project. So we can click on the button at the bottom left hand side and now we can see here web application simple is the active project, unless you wanted to change that. We wanted it to be ASPPLAY, we could select that here. So we can actually toggle back and forth between those two this way. It's kind of important to know that the way this works with ASP.NET is when VSCode sees a project JSON file it opens up a DNX project. And that's for the new stuff in ASP.NET 5. And it will also load all of its reference projects that it finds in the project JSON file. If you open a folder, it's actually going to do a folder scanned and look for every project that it's got and load them all. And if you happen to be using a solution file, an SLN file, they'll actually open up a MS build project and we'll also load it any sibling or reference projects that it has. So VSCode tries to be smart about what kind of a project you're opening. Now let's say you're inside of the home controller here and inside of C# we get some basic features like format on type, so you can type in public class customer. And as soon as I type in that curly barce and hit Enter, it's going to move them down where it wants them. And we can take advantage of some snippets we can have in Prop, we get an automatic property or a full property back in field or one with a get accessor in a private set, we'll try the first one. We type that in, let's say we want this to be a string. And we want that property to be called, let's say, full name. So we can see we can take advantage of snippets here too. And now let's say we had a function down in here and we'll create a function called testFunc. And we want to make that have a return type of void for now. And we set this function up, maybe we want to create a new instance of customer. You say varc = a new customer. Notice we've got that right here and we have Intellisense for it. And now we can say c. and we've got our full name right there. So we're getting full on Intellisense. Now when we do that, you can notice here that we've got full name and we can hover over it and it's going to tell us what exactly that is. And as you might imagine, if I hit F12 on here, it's actually going to go right up to the definition to reference on line 12. So we can also come up here, again we can right click this time, do final references or F12 with a shift. And it's going to show us all the references that we see for that. One of the cool features we have here is, let's go back into Preferences, because I've turned this off for now, there's actually a thing called editor reference infos. Notice I've turned that to false over here in my preferences, let's turn that to true and see what happens. Now we'll close this one out and that one and we'll go back into the home controller and now inside of there suddenly appears all the references. Now we can see there's one reference of full name somewhere else. But click on that, it's the same thing as finding all the references for that guy. So let's just make a little test down here, let's copy that testFunc and let's paste it. I'm going to call testFunc2 just to show we can do this twice, now I can automatically see two references to this property and two references to this class. If we created another instance of the class inside of the same function here, we'll call this one C2, we should now see three for the class and then two for the property. So VSCode is pretty smart about this, now that's kind of cool because it's all in the same file. But what if I created a new file here? So I can create a file a different way, let's right click over here, create a new file. I'll call this customer.cs and now we'll use our split panes, come back over here, and let's copy out the customer from this file to another file. And we use the same namespace, paste it over there, and let's remove customer from here. Now once again we've got customer on the right and on the left over here we're still seeing that we can instantiate customer, we still have Intellisense, we've still have got our hovering features. And we still see the reference information on the right hand side. Well let's say we want to search for symbols inside of our file, we can do that with Command + Shift + L. And now again we can see the controller itself and then again we'll highlight the different functions as we go through them as we see those. And if I do a colon after that, it'll separate it out by classes and methods by telling me over on the right hand side, that's one of my favorite features so it kind of makes it easier to find them. And of course you can search for things and it does a contain search of found the b in the word about. Maybe I can find all the words of controller. Yeah but what renaming and refactoring? Maybe I don't want this to be called full name? So I could right click on this and rename the symbol or I could hit F2. We'll try it this way for now and we're going to type up the full name and let's instead call this just name. And when I do that, notice it changes the name in a couple different places down here on line 20, on line 15, and then back over here on line 6 of the customer cs. But wait, there's more. What if you want to run a DNX project with C# and ASP.NET? Well if you setup ASP.NET 5 and it can see inside of your project JSON file. We'll close that guy on the right. That it has a kestrel command. Well the kestrel command is what runs it over on OSX, so we can run any commands that we have in our project JSON. So how do we do that? We can hit Command + Shift + P and we'll type in DNX and you can see it's going to read out the different commands inside of this file. You'll see kestrel and web, but you'll also see the DNU restorer, which is going to the update basically to restore everything for .NET. So we could use that and run kestrel, it's going to crank up terminal, now it says started, so we could actually then go to a browser. And in that browser we could hit local is 5000, because that's the port that it was set to. And we can see that's actually running here. And if show that on one side and show the terminal on the other you can see that it actually hit right here on the right hand side. So if I clear that out, and I refresh you'll see it hit it again. So this is basically coming out of the ASP.NET generator that they have on their website. And I also put the same project inside the course files. Then I can kill the session using Ctrl + Z and then I close that particular terminal window. But it shows you can actually run ASP.NET sessions right out of Visual Studio Code.
-
JavaScript
Now let's take a look inside the CodePlay project, which is ES5 or JavaScript. So when we're playing inside of JavaScript we'll open up a file like the dashboard controller. And we can get a bunch of things in here, such as formatting on typing. So you type in function and then this could be a fakeFunc and we hit Enter. And it's going to automatically move the curly braces where we need them. And let's say we had that all off down here like that and we got some extra indenting over here. If we want to format that, we can go over to the command pallet and look for that. Or we can just hit the Option + Shift and F on the Mac or just replace Option with Alt on a PC. And it'll format the code, you don't have to highlight the file to do that. Now we also had snippets inside of here, so we could type things in, let's say we wanted to add a new function inside of there. We type in FUN and there's a function where we see that little square that means it's going to be a snippet. And if we type in a function here, it could be another one. And we can type in a parameter name here, maybe just x and move along. And it's giving us a warning, well if you want to find out what their warning is, we can hover it and it tells an unused local function. Or let's say we're down here and we want to hit the F8 key, it's going to go up there and show me the warnings. The warnings are green. And we can see those denoted down here in the bottom left as well and we click up into here. And our command pallet opens up with the bang. And when you want to get out of that mode, just hit Escape. So I you want to see what some basic validations are, you can go to the preferences we hit Command + , to go see those. Command + B to make it a little bit wider. And now let's just take a scan through here we'll do a Command + Shift + O, you can see our symbols and we'll look for the word JavaScript. You can see a bunch of different things in here, for example making sure curly braces must not be omitted. Right now it's set to ignore, if you don't want it to make sure people put the curly braces in, you could say okay I need that to be here. And you can set it to be a warning, for example. So that's over here in this side, well I set a few over here for me, like right there I see curly braces must not be omitted, we'll make this a little bit easier to see. Right now I've got it set to be a warning and I could change that from warning to ignore, which is the default or even to error. So let's leave it there error for a more and we'll flip back over and we'll come back down into dashboard controller and let's add a little if statement. And we'll set a variable like x equal to true and then we'll say if x we want to return. Now in this case I'm not using the curly braces, because I don't have to, because of JavaScript, but it says here I have to do so. Why? Because I set that rule, so if I hit the F8 key, we're going to see the warnings because I'm not using the x. And then we're also going to see the error, don't spare the curly brackets. Now if I change this over here, back from error to a warning, now I come back over here now I notice it turned green. Still tells me it, but it's not an error now, it's a warning. And if I delete this entirely and just go back to ignore, now I come back over here it really doesn't care that I didn't put them in place. So I'm going to leave it at warning, because I happen to like them there. But you can see all the different ones that you can override, I've overridden these right here on the right hand side, because I wanted to give warnings to these particular things. And again I can go back into Command + , and I can see all of them if I go back inside of my symbols. So I can skim through and see what is available here and then take a look and see what I want to override. One last cool thing to take a look at, is sometimes you want to change a global variable to say, you know what, I know it's global variable, I'm okay with it. For example, inside of a unit test, like right here I've got this spec file. I happen to know that these data service and controller and things like this use variables this utility called bard is going to set those up to be global variables for me and then it's going to tear them away for me too. So I know it's okay in this particular case that I want them to be global. So what I could do, it's telling me of the warning, saying hey, you know, I don't like you have the global here. What we could do is come right on top of it and we could do command . and that's called a quick fix or a code action. And it says here mark data serves as global. And it puts it up top. And then if you'd like to, we could just type in more up here like $controller and you'll notice that that's going to go away as well. In the future I expect that they'll have a project setting that'll allow us to do this for, but this is a good first step.
-
JavaScript Intellisense
Now we're just in a plain old ES5 JavaScript project, which means we're not going to get any help with any IntelliSense on anything, right? Well maybe. So we're got this typings folder opened up, those are actually typescripted files that are going to give us definitions of what the JavaScript files need. So what does that mean? Well let's take a look back at that dashboard controller again inside of there notice it knows raising Angular, I'm getting some IntelliSense and some hints that that's an Angular object. And I can hover over $q and I can actually get IntelliSense if I use that. So down here if I say $q. I'm going to get all the different things that are hanging off that object. Where is it all coming from? Well let's take a look back inside of typings file we get this Angular folder and it's got an Angular.d.ts. That's an Angular definition file for typescript, or we call them typings files for short. So now if you open that up, somebody has gone to the pains of typing in all basically the interfaces for Angular. So you can see this files quite large if we go to the bottom with a command down arrow, this code doesn't execute in your project, it's just for helping you out at development time. So let's go ahead and just remove that entire folder, Angularjs, we'll move it to the trash. And for good measure we'll do the same thing with something down here called toaster. I could right-click it or if we want to, you can just click on top of it and do a command delete or backspace and move to trash. Now they're not there. So let's go back up inside of our dashboard and now you can see it's like, uh-ho I don't know what Angular is, what am I going to do? So, let's take a look at how this works again. If we go back into our terminal we can use the definitely typed GitHub repo to help us get those tubings files. Well wait a minute, what is that thing he's talking about? So let's take a look at that. Up here this is definitely type repository, which is basically listing off a whole bunch of different libraries with these typings files. And if you look down here, you're going to see we've got a lot of Angular stuff going on too. Right down here at the bottom there's our Angular one. And that contains the files that we might want to go get. So we want this Angular.d.ts file. So how do we get that without just downloading it? Well let's go over to our terminal and we'll open up code again. Here's where we take advantage of a library called TSD. So TSD, we take a look inside this file that we have here, I've already used it to get these files. It creates a JSON file, it says, here's the things you asked for and that's where they're located. So how did these get in here in the first place? Well let's go ahead and find out. First of all, you can see I had one for Angular, but let's say it wasn't in there. I could type in tsd, well how do you get tsd? You could type an npm install, tsd-g to install globally. I've already got it in my machine, but if you haven't done so, please go ahead and do that. After you get it we're going to use the tsk interface to install Angular's typing file. So the syntax is, tsd query, it's going to search for it, -r for recursive, -0 for overriding in case it's there, -a for the action, which will be install. And then we'll type in Angularjs. Well what's recursive? Recursive means any dependent libraries that Angular may have, for example, jQuery. We'll also get its dts file put into our project. And I want to save that inside of our tsd JSON file, which we're taking a look at. And we make sure we're looking for Angular and then I'll hit Enter. Notice it found Angularjs and it's going to find jQuery. So both of those are there now, now we go back up inside of our dashboard file. Now it's happy, it knows that Angular is once again. And what they're to actually do, well if you scroll back down notice Angularjs is back in our typings files. Now if we found a place that was using toaster we'd see the same problem. So what you could do is you could type in Angular here and the you could type in toaster right after it with spaces, it'll actually go get both of those. So now you can see it's getting Angular and it's getting toaster, they both happen to require jQuery. So it's putting them both in our project. So do you need to worry about and adding all these files to your project? No not really, and if you didn't want to check this into source control you could actually add that to your get ignore file. I happen to like putting them in there because that means that when somebody goes to grab my code, they automatically get the great tooling support. And notice I don't have to have any reference files or anything inside of this project to say that I'm using Angular. It just knows because it picks it up inside of the typings folder. Speaking of IntelliSense, let's flip over to the server. So now we get the server file, it's not much of a server, it's a very small file. And I might want to get IntelliSense in here. Like notice it doesn't know what process is and I can hit the F8 or hover and I can go and see, oh it doesn't know what that is. So I could get a hint in here. I could do a command . and it could say, alright go ahead and add a reference to the node.d.ts file. Now when I do that it's actually going to something special. So let's hit Escape for a minute and not do that first. Let's open the typings folder and you'll notice no it is not in the typings. Now let's keep our eye on that bottom left and let's go put our cursor back on process we'll hit the lightbulb this time, we could hit command . as well. We'll add the reference and notice I added the reference up here, but it also put the node file down here in the typings. So when it did that, we no longer need this reference file up in the top I can just get rid of it. And notice now it knows exactly what process is, it's a nodejs process. So to prove that, let's go ahead and type in process. and now you can see all the different methods that it's got hanging off it and properties. Could I have used tsd to grab that too? Absolutely, but now it's showing us that we're going to get IntelliSense fully inside of our node files too. And notice here I'm actually referring to another module called utils/404. So let's go take a look at that, there's utils and there's 404, I'm going to hold the command down open it next to it. And that's just a minor little module and it's got some methods like send 404 and it's got the not found middleware. So what happens over here if I type in 404 like this and I do . it's going to automatically get IntelliSense for those. And didn't have to do anything to get that. So we're getting stuff out-of-the-box for modules that it finds. And for ones that it can't find, like node, we can just pull down the typings file into our project and automatically our tooling picks it up and we're ready to roll.
-
ES6 Gulp
There's another project that we have with our source code here and it's called ES6 play. Let's open that up with code. Now this project is a very simple ES6 project, we've got our source code here in a js folder. This is a sample that my good friend Dan Wahlin and I put together. Now let's take a look at what we get out-of-the-box with Visual Studio code. First let's run this. So I'm going to run it from the command line, there's a command line that you get here. You do gulp serve, all you have to do is make sure you've installed gulp, so let's make sure you've done that if you're not sure of the command, you can do npm install. We can do gulp-g. I've already got some on my machine, so I'm good, but you can enter that command. And I'm going to type in gulp serve. Now it's going to run that and it's actually going to launch this project right here in the browser. And it's just going to show a couple of cars and some trucks. And if we show the developer tools we can open those up and refresh and we can see we have no errors over here, we can take a quick look at the network traffic as well, awesome. So it's actually running our server and connecting the client browser for us. And I'll hit Ctrl + C to kill that and Command + K to clear it. Now back in Visual Studio code now that we know our project runs, let's take a look at the main js file. Up here you can see I've got an import statement using ES6 for importing car and truck from this autos module. Well how does it know what car and truck are? Notice down here, if I start typing in car. I'm going to get in these two methods, get details and total, and then a bunch of properties and it knows what those things are. So how does it know that? It's looking for this autos module, which is right here. So open that up onto the right hand side. And there I've got some ES6 classes for things like auto and car and truck. So the ES code is very aware of what ES6, but how does it know when it's ES6 versus ES5? Well that's where this js config JSON file comes in, it's right in on the root. So let's close one of the files and let's open up the JSON config. And it's a very simple JSON file and notice it says target is ES6. So let's play a little trick on it. Let's go ahead and open up a second window and we'll go back and show the main file. And now let's come over here and change the target to ES5. Now if we do that notice on the left-hand side it's like, dude I don't know what these statements are, this let thing you're trying, that's just not real. And the error message is telling us it can only be used with ES6, so you want to make sure you've got a JSON config JSON file, which will set that target. So if we really want to play around we can go and set it to ES3, I hope you're not doing that, but then anything that's breaking ES3 would also show up. So we'll flip that back over, but you'll notice that it's going to help us out with all of our IntelliSense and any errors that we have in our project. There's other settings inside of here too, for example we can come down here, hit Ctrl + Space, you'll see files. So I generally keep files empty, meaning I don't even specify it, because if there's no files property there, the language service is going to default to looking for all files. And I you want to read that a little bit better, let's go ahead and let's try it again. Now you can see it's going to validate all the files, but what if I type in files here and let's type in a single file like js/mainjs. Now if I open up that second file and that happens to be main it's like, hey I know what that is, I'm good to go. Well what happens if I open up the autos file over there? It's not good. So you can put in your files here if you want, that's an array of files and you can do matching if you'd like to. But as that files entry exists, notice the right-hand side, it's not going to like that. So if you get rid of all those though once the file saves, it should be happy with all of your ES6. Now a couple of tricks here, wherever you happen to put that JS config JSON file, that is really the root of your JavaScript ES6 project. In this case it happens to be ES6 for me at least. So what does that mean? It means that you have a multiproject folder where you've got different folders with different projects in it. Every time it sees a JSON config JSON file it's going to look and say, okay all the files underneath this level are going to apply to this particular JSON config JSON file. So where is that useful? Well maybe you've got two different folders in here, one for client and for server. Maybe on the server you're using ES6 and on the client using ES5. Well then your client folder you could create a JSON config that's at the ES5 and in your server folder you create a JSON config set the ES6 as your target. Now I'll teach you a quick trick that sometimes things don't reload automatically and they seem to work really fine for me right now, which is great. But if they don't, you can always go into the command pallet and type reload window. Just remember, vs code's basically just running on a browser and the whole thing just can reload. So sometimes these files don't actually like kick in, go ahead and try the reload trick. And don't worry if I slipped in a little bit of a gulp before, and right typed over here and I typed gulp serve and it launched the browser, because you could do this from the terminal, but we'll show you how you can do that right from Visual Studio code as well. Okay, let's do it right now. So if we go up to the command pallet, we typed in the command name here for task. And we can see we can run a task and it'll just put the word task up there. And notice it's searching for some task names, babel, default, serve, and watch. Where are those coming from? Well let's escape out of there and take a quick look. If we click inside of our gulp file we can see we've got these tasks like babel, watch, serve and we've also got one down here called default. So how did we get to that point? It's actually scanning our code for a gulp file, which is for task automation, so we can go back up into here, we could type task, run task or we could use a keystroke. And after that task we can type in serve and then it automatically will run that and launch the browser. So I never had to go to terminal, it actually does that for me. And don't worry, we'll take a deeper look at tasks and how you can step up your own tasks in a later module.
-
TypeScript
So what about typescript? Now we showed how you can use typescripts typings files with JavaScript, but we can also use it with typescript of course. So let's take a look at this example we have called tsplay in your source code. And we'll open that one up inside of vs code. And here we go. So what does typescript look like here? We've got our source files and then we can go up and open up our app. And we've got the dashboard, in this case we got dashboard controller ts. So there it is looking at typescript. So inside of here I could create new properties if I wanted to, we can create a new property called my newprop. And this one here we can set it equal to let's say we create a value called papa. In this case is it going to know what it is? It does indeed know that it's a string when I hover over on top of it. So let's say I create another property in here and that property let's call it mystring. And we'll actually define this as being a type string, we need a colon there. And we can set it equal to something, let's set it equal to 1. Oops it knows we've got a problem. So it knows right out of the gate that we've got a problem here because it's typescript and that gives a little added advantage at design time which is great for developing. So you can type something in like newprop and that's going to be this.newprop just like that and it's all good to go. Now where is that defined? We could just stick there, we could hold our command key and then click on it. Notice that becomes a hyperlink and before we actually click we can see a little hover there, it shows us what's going on and where it's being peaked at. And we can click on it and it goes right to the definition. So that's kind of cool, a lot of little things there. Hover shows you a little bit of what this type is for the property hold the command down gives you a little peak while you're hovering of what it's looking like. And then you can click on it to go to the definition of that particular property. Not so exciting here, well let's take a look at a little bit of how a cross file reference can work. So up top we can see we've got q and we can see we've got the data service. Well we can hover over that and we get a little of where it's used, notice it's right here. And notice it's a type of this app core IDataService, which is an interface in typescript. So if I hold a command key on that, we're actually going to see the interface for IDataService, which is in another file. So we have cross file references. So if I click on that as you might imagine, it's going to take us to the data service ts and the interface for IDataService, which is exported from that file. And on here, if I'd like to, I can do final references, which we can right-click again or do a Shift + F12, we find all those references and you'll notice one of those happens to be the dashboard controller. Which I can just scroll down with my arrows and then I can go right back into that file if I wanted to just by double-clicking in it, and I'm good. So you can see in typescript you get a really rich experience. We can also do our Command + Shift + O and search through all of our symbols and we can sort them by putting the colon after it. And see this particular guy he's got quite a bit, he's got one class, one interface, a couple of methods, there's the module itself, and then a bunch of properties. If our code isn't looking so hot, like maybe I have some indenting problems over here, I can actually just use the format feature again with the keystrokes. It'll automatically snap it back into place. So what's helping us out with this? Well as you might have guessed, we've got these typings files again, which are telling us all about these third-party references. They didn't help us with the data service, it happened to be referenced from the dashboard, those things are automatically taken care of by vs code and typescript. But these third-party ones come from our typings files right down here. And they get aggregated in this tsd.d.ts, which again is just pulled together for your development time experience. These do not get deployed anywhere. So there's an extra file that we can stick into here and this a typescript specific file. Let's go ahead and close these up so we can look at it. Inside of the app folder we've got all of our typescript, but right below that notice we've got this ts config JSON. Just like the js config JSON, this is his sister. And this one helps you by setting up typescripts specific configuration. In this case we'll set up noImplicitAny to true, which means that you cannot have a datatype that's not explicitly set to any or to some other type. And it's got other settings like targeting where is my transpiler going to go to, it's going to be ES5 when I transpile it because I'll probably throw it in a browser. And we do want to generate source map. So this helps you by turning on any typescript specific features that you need. And just the like the js config JSON, wherever that sits, that's basically the typescript projects root So notice I put that in the client because that's where I'm using that. Then over in my server I've got its own ts config JSON and in this case I'm setting the module type to be commonjs. That way I can transpile it down to use commonjs, still to ES5, and then all of my code takes advantage of those features. We'll go back inside of our dashboard controller because we seem to like going there. Let's go inside of a function. So we'll create a function called myfun and let's create a hello world. And we'll do a little bit of type checking here. So we'll create another variable called y and we'll say, alright x if we do a car at in that particular spots going to be, let's take a look for, I don't know, let's look for a d. What's going on, why has this got a problem? It'll actually tell us the argument type strings is not assignable. So that's kind of cool. It's telling us that this function has a variable inside of it, a parameter, that is not meeting that type. So let's take a closer look, let's delete some of this. Now I can do the parenthesis, notice that it's saying pause has to be a number. And you may have noticed briefly when I typed charAt it actually showed that. So let's delete that again and type in carat and when I do that we can see the signature there. And then we can hit Tab and it actually shows us a placeholder for that value. So now I could type in a number and I'd be good to go. So let's take a look how we can build our typescript in here. And to show that we're going to show both the typescript file, which we have open, and then the JavaScript right next to it. And we'll get rid of that for a moment. So now we can say, alright let's take a look at this. I'm actually going to delete out that JavaScript for just a moment just to prove that it's actually going to build. And we're going to hit Command + Shift + P we're going to run task, and then you can see the task is tsc, that's in my task file, which we'll take a look at in just a moment. We'll hit that, in the bottom left-hand corner you can briefly see a little spinning wheel, it stops, and then the right-hand side you can see it just transpiled our typescript into ES5 JavaScript. So let's take a quick look at that again and we're going to have an entire module later on tasks to show us how to set these up ourselves. But if we go back in there and look we can see when I typed in task, you can actually run a build task too. So I could hit Command + Shift + B to run the build task. Well what's that look like? So we're going to go look at configuring the task runner for a moment. We could say the command is tsc, that's our typescript compiler, which of course you want to make sure you've got. And you can install that through npm install-g.tsc. And then I'm simply telling it, okay start with this folder, what folder? It's going to be source client. And that's it. So that's one way we can set up simple tasks using the task JSON file. And we'll look deeper at this in one of the later modules.
-
Feature Overview
Code has a whole bunch of features from many different kinds of languages, as we took a look at here in this module. We looked at just some of them, such as JavaScript and typescript in HTML. But many more are sure to come. We scanned through some of the HTML and the syntax highlighting was pretty cool, but Emmet is really what helps make it go really fast. And we also get some Angular help, which is cool for me because I happen to like Angular. But we've also got CSS, Less, and Sass help, we took a look at the first two, and we get things like previews in all three of these, so we can see where these things are actually used and what elements they would match to an HTML. We get IntelliSense for the features themselves. And we can actually see every place that they're being used, which is wicked cool. All this is really useful. And it doesn't stop there, we took a look at some of the JSON things, like the schemas and the syntax highlighting. Which really helps us so we can fill in the right properties for JSON. And we can go to assemble directly by using our go to symbol command, Command + Shift + O if you haven't figured that one out yet, because I use that quite a lot. And I happen to really like how in bower and npm we can look things up in those registries directly by using our Ctrl + Space. And if you like markdown, like I do, it's really cool that you have live preview right inside of code. And I happen to like customizing my CSS to make it look like either GitHub or sometimes I get a little more stylish, as you saw here in this module. So you can set that up right inside your preferences. And when you start to code we can look at things like C# or we get a much richer experience with things like IntelliSense and multiple kinds of references, reference counting. Go to our symbols again or we can even run commands directly from Visual Studio code so we don't have to go to terminal. And if you happen to like JavaScript or typescripting code, no worries, with JavaScript we can ES5 or ES6. In ES5 we got things like formatting or outlining, or snippets, but we can also take advantage of the typings file so we can get a little bit of IntelliSense. In ES6 we can also get that as well. And then of course if we use typescript we can use things like references and symbols as well. So we get a top notch experience with typescript, because we can figure out so much more based upon the typings and the interfaces. All in all, you can see there's a whole bunch of things that you can do inside of code and it has a rich set of language features. And you saw a quick glimpse in this module to of how we can run tasks. Well we'll look more at tasks and debugging and the good integration coming up very soon.
-
Version Control and Git
Code Integration with Version Control and Git
Using source control is an integral part of any development experience. So Visual Studio code has some integration with git and version control. This module will take a look at what it offers for us. Out-of-the-box code integrates with git, that means you can use any git provider that you want. Of course you have to install git first and you can do that right here from this download if you haven't done so already. And once you do you can connect to any local repo or a remote repo, such as one on GitHub. Do you have to use git commands right out of code? Of course not. You can use another tool like source tree or smart git or you can just revert back to the command line too. The commands inside of Visual Studio code are just a convenience. Some of the most popular remote online providers, that you can use the git, are things like GitHub or Visual Studio Online or Bitbucket. But remember you can use any git provider you like. But to get things started let's take a tour of all of codes git features. Most of these can be found inside the git viewlet, but there's others as well, like in the status bar. We've also go gutter indicators for files. They'll tell us things like hey have you got lines added or changed or removed? And if you'd like to see what's happening behind the scenes, you can actually take a look at the git output too. And of course any git tool wouldn't be complete without being able to show you what's changed and also what those diffs are. So let's step right in.
-
Touring Code’s Git Features
Let's start by taking a look at the git viewlet. Now you can open that up in the left-hand side of your pane and you can see here that I've got four different kinds of changes. And there are some subtle indicators as well, so when you're not in this view you can see the changes exist. For example on the far left, right on top of the git icon, you can see there's four changes and then in the bottom left you can see that the branch I'm on has a star next to it, saying that there's some changes there. And the changes are color coded and have a letter kind of designating what type of change they are. So right at the top we've got a stage new file or an add. And then there's a deleted file in red and the M stands for a modified file that I might have changed, such as an HTML. And then an unstaged new file. As long as vs code knows that this is a git repo it'll keep up with these changes for you. So let's jump into some of our code and see how we can manage some of these changes.
-
Working with Version Control
Now let's jump into one of our code samples here, codeplay, and you notice we have no git changes, I can see that, because looking at the indicator, there's nothing there. If I click on it you'll see no changes. Well let's open this up just a little bit so we can read more as it comes through. First, let's go back over here and let's open up the dashboard controller. And let's first just delete a line of code. We'll delete that comment right there. And notice that we have an indicator on the far left. So we flip back over here, we can see there's a modified change. Now if we click on that we're going to see that we've got a diff and the diff is showing in red, the line that was deleted, and green the line that was added. If you don't like this inline view you can go to the upper right and click on the three dots and you can switch to the side by side view. Now we can see side by side the line that was removed and the line that was added. Let's go back over to our regular view. Now let's make a couple more changes. Let's say that we didn't want this activate function at all, let's just remove it. Now if we do that, these other functions aren't being called, so we get little green squiggles that's okay we're just playing around for now. We click back in the dashboard we can see more that's going on with the diff. And again we can flip back to the single view in line and we can see what's happening here too. So you can pick your favorite. I happen to like the side by side personally. Now this is a modified change and notice it's sitting right here as an M. Well what happens if we want to stage that change? We can hit the plus sign right there and now we stage that change. So it moves up to stage changes. We'll just leave it there for a moment if we made a mistake we could always just hit the minus sign right there to get rid of this one file or multiple. Let's see that in action. Now let's open up the dashboard route. And in here let's also just add in a couple lines of spaces, we'll come back over to the git, because of auto save on it, it's automatically seeing those. Notice I have staged changes and unstage, that's how you stage this one too. Now I could unstage one at a time or I could unstage them all like this. So we'll go back and we'll stage just one of them. Alright but what about deleting files? Let's say I didn't need this file right here. You can come through here, we could right-click it, and do delete. Now we can move it to trash. Well let's say we also didn't want this speck file another way to do it is Command + Delete or Ctrl + Delete and I can move that over to the trash, go back into git changes now you see four. We'll see the deleted files. Now the cool thing about this is if you've got git running locally or you've got one connected remotely as well, you're going to be able to see these changes and it makes it really easy to say, hey I can play around, I can delete files, add files, and then at the top I can come up here and say, clean them all. And that'll reset them all to their original state, let's try that. So now I'm going to clean all these changes and it puts it back to normal. But wait, what happened to the stage ones? Oh that's because I staged that change. So if I unstage that, now I can clean them all or you can come up here and you can do this little guy right there. And that's a single clean and I hit clean changes. Now let's go back and make some changes again and notice our files are back. And let's delete a line of code again, just so you've got some diffs, we'll get rid of activate down here. Actually let's just change it around, let's say activate to something silly like console log. Now let's delete a file, we'll get rid of this spec file, yep we want to move into trash. Now let's add a new file in here, we'll call him John, I'll make him a markdown file. And we'll say hello John. And then we'll save that file right there. We come over in here and we can see we've got an unstaged add, let's say we want to stage that notice he turns green. And what if you want to see a diff there? In this case you're not going to see a diff because it's the only thing in there. If I do the modified you'll see the diff and if I see the delete you're just going to see the file that you're deleting. So how do you commit these? Well you can come in here and you can highlight the file and you can see what's there, you say I'm good to go. And you could just say, no matter what you've selected down below that I could put this in and say I'm omitting a new readme. So now what I can do is I can do multiline commits messages, so I can keep hitting the Enter key. And I can put something else here, like something else. And if I want I can do Command + Enter and that's going to commit that. Now it just committed that to my local repo. So now John is a file that's already there and I'm not going to see that showing in my git changes any more. But what about these guys? Well I can commit those too if I like, or at this point if I want I can go back and I can delete John. Now the John is already in there, and he's been committed. At this point we're going to see John show up as a deleted file. So now I can go and put him in there, stage that guy and say, removed changed my mind. And again I can use Command + Enter or if don't like that I can come up here and do a commit staged. And that commits that staged one. Now if we look down at the bottom corner we can see that we've got some changes down here that's based upon this little guy in the status bar. And if I click on him you're going to see the pallet open up with some commands like git checkout. If there was another branch I could actually check another branch here. Let's create a branch called develop. Now I've got a branch called develop that I'm actually working on. But what if I wanted to go back to the master, if I click on that again I git checkout, it see that's I've a master branch. So I could type in master or I could just click on that now I'm back to master. And again now that I have a developed branch it'll see that. So I can actually branch really easily right here inside of Visual Studio code. And let's take a look at these files themselves. Notice we had these diffs right there, if I go back into the file, right over here, you're going to notice some blue lines. There's a blue line for the modification and there's another blue line for the modification. Those are our gutter indicators in the file. If I delete a line, let's say I don't like this use strict, I'll get rid of that guy. Notice I've got a red triangle, it's not a line because you've actually removed a line from there. So I'll delete again, it's actually removed two lines. If we go back to the diff mode, now we can see those two lines are removed. So coming back in here we now see we've got deleted lines, we've got modified lines, and let's add something down here like hello and that will become green. So right out-of-the-box you can see these indicators and that also works with the dark theme. So I go in my command pallet that'll be Command + Shift + P and I type in dark and I can see the dark and again you can see the red, the blue, and the green, which represent deleted, modified, or changed lines. And again they'll show up inside of your diff right over here. So that's how you use the basic git commands inside of code.
-
Git Output
I've reset all my code changes and I'm back in the master branch and let's say I'm a new git user and I want to learn what some of these git commands are. Or maybe on the other side, I'm an experienced git user and I want to make sure the commands it's running inside of code are the ones I expected to be running. So how could I do that? Well let's go over to the git panel right here in the viewlet and we'll open up and show the git output. So right here I can see it's got a bunch of messages, it's showing me the commands that it's running. I'm going to clear those in the upper right-hand corner to clear out that output. And now let's go back into our file. Here's the dashboard controller, let's delete a line right here. And let's go back into git and now let's show that output. Now to show the output first I'm going to hit Command + 2 so I can open a second panel. And then, because it's the active panel, I'm going to hit Show git output and it's going to put it over on the right-hand side. So I'm going to clear out that output again and then now let's see what that command is, it's actually using git add to push that up there. So we can move that over and we can take a look and say, alright there's the commands. And if I want to stop looking at this, I can just hit that out. Now let's say I wanted to get rid of that, I want to stage anymore, I want to take it out of there and unstage it. Now we can see the reset. So it's a great way to learn some simple commands. You can also come up here and we can do a clean all and it's going to say are you sure about that? And we're going to say okay so it's doing a git clean and it's forcing it and then it's going to check out the current branch. And then we're good to go. So this is a just a quick and easy way to see some of the commands that are being run inside of code.
-
Creating a New Local and Remote Repository from Scratch
Sometimes I just start writing code and then later I think, this is a great idea, I want to push this up into git. So let's see how it might work. First let's go create an empty folder to put our new thoughts and we'll call this new idea. And then we'll go inside of new idea and now let's say I want to start working. Well I can type code., because we have that quick old command line we created, and there we go, we've got a newly opened code editor. And inside of the git tab it says would you like to initialize this git repository? Well maybe I haven't thought that far yet, so let's not do that. Now I could right-click in here, do new file, and we could say okay I'm definitely going to want an index HTML, let's do that. And inside of here I can use this to create a little bit of HTML. And let's say I want a new file for putting my JavaScript, so a Command + N, and I want to put this and call it apjs. Come up there, I'll save it as apjs, make sure it's in the right folder. So that's a good starting point, I've got my HTML and I've got my JavaScript. So let's say it was an Angular project. Now I'll come back over to terminal and for this I want to start using bower. I could say, alright I want to initialize my bower file and I use the bower init. And to get this I need to install bowers by saying npm install bower-g. And I'm just going to hit Enter for all of these questions, because that's a lot of questions. Notice that my file appears over here now. Now once I have that I can come back over in here and I can say, let's go ahead and use bower install angular and we'll ---save. Now it's going to pull the latest version of Angular down, if I look back at my bower file we can see the dependency. And we can see it in the bower components. That's pretty good. Now if I click over on git we can see we still don't have a repository. Now I'm starting to get into writing some code and I'm like, you know what, I should click this button what that's going to do is initialize and get repository for me. Now it shows me all the changes. Now there's a lot of changes in there that I don't necessarily want, so how might I get rid of all of these ones in the bower components folder? Well I can go back into here and now I can create a file called .gitignore. And it's going to warn me about the dot, which is okay. And notice I still have all those commands there, but I don't want anything that's under the bower components folder to be there. So I want to save that and now notice it went down to four files, because it's ignoring all those others. I'm still playing with the local repository too. Now let's start writing some code inside of my HTML I happen to want to create a controller and an application. So up in here I'm going to do ng-app and notice I'm getting my IntelliSense. And my apps going to be called app. Well what is that thing? Well let's open up our appjs and we'll do it side by side and we'll get rid of that file right there. And now we're just going to say, okay we're going to use a snippet and you can grab these off of my ng styles website at this location right here. And there's instructions to install on there as well. And for this I'm going to say, go ahead and create an ng controller. And let's stretch this over a little bit so we can see more what's going on. I want to call this module app and hit Tab, let's call this my home controller. We'll make the dependency $log, which is just a logging service that Angular gives you. And in this case I actually want to define a new module, so I can put a comma and then two square brackets up there to say define that app module. If you want to learn more about Angular you can check out my course Angular Clean Code right here on Pluralsight. Now let's just create a simple property called title and let's set this to be hello world. So we have this very simple controller called HomeController. We'll come back into our code over here now and we want to use this. So let's create a div and that div we can take advantage of Emmett, we want to make sure we can use this ng controller. And we can say, okay set that to be this. And we also want to say as vm at the end then we hit Tab and it's going to automatically put everything together. So let's go get rid of the side so we can see all the code we've got. And there's out div. Now I want to say, go show me the title. So it's going to run this code, but it's not actually using our script tags. So here again we can take advantage of Emmett and we know a script tag needs a source. And that first source is going to be my appjs, right? So there's our script tag and before I do that, I need my Angular one. So I have to go get Angular and we know that's in our bower components. And it's in a folder called Angular and it's called angular.js. And we go to the end and we tab that and we'll go verify that that's the name, bower angular, angular.js. Good. Now let's try to run this application. I'm going to clear the screen with Command + K. Now we need a simple server just to run this, so to do that you can install something called HTTP server. It's called HTTP-server like this with a --g command, that'll put it globally. I happen to already have that on my machine. If you're not sure if you have it, what you can do is npm list --g ---depth =0. This will show you all of our list or all of the components that npm's installed globally. And the depth 0 make sure doesn't show all the nesting components. So by doing that you can see I've got HTTP server on my machine. Now what I can do is type HTTP --server and that just runs a basic server right there on port 8080. So now let's go open up Chrome and let's go up here and let's open a new tab. We'll go to local host 8080 and there's hello world. Awesome. So our application works. But that's all local, right? So we field back to code we can see that we've got this git repository locally and we've got all these changes, but let's say we're ready to go now. So let's go ahead and initialize this. And hit Command + Enter, there all local, but I want to push this up to git. And on git I generally like to have a readme, so we'll do a Command + N again and we'll save this file. And we'll call it readme.md. And in here I'll put it called new ideas and we'll go back over into our git here with a commit and we'll say add it a readme. But it's still not up on my public git repository. So how might I do that? Well let's flip back over into the web browser and I'm going to my personal GitHub repository, you're going to have to go yours. And I had to create a new repository. So up here I'm going to call this thing the same name as my project. And just make sure you match it up with yours because it's generally just a good practice. You don't have to I guess, I'm going to call this one new idea. And I'm going to leave it with no description and public and I'm not going to initialize it with these files because I've already got my own. So when I do that with no files it's giving me instructions on how I could actually push this remotely. So now I'm going to take this command here, it says git remote add origin it's basically going to go back to my command line and I'm going to run this in the command line so I can connect my local repository with this remote repository. And then I can run git push, it's going to set the upstream, they call it, to be the master branch right here in this repo. So I can copy these guys just by clicking that button or you can copy and paste by highlighting it like this. And now let's flip back over to the terminal. And let's open up code on the left-hand side. Now right here I'm going to stop the server by hitting Ctrl + C. Hit Command + K to clear it out and then I'm going to paste. When I paste it the first one it set the remote and now it's going to run the git push up to that remote repository. And if it works you should see a message like this. Notice nothing changed over on this side but now if I flip back over into my GitHub repository on the web, and I click on new idea, we should see all that code just got pushed up there. And my reading file's there and everything. And look mom, there's my JavaScript. So we can close out of Chrome and let's say we wanted to make some changes here. Now that I've got a remote I'll go back into the file and say new ideas, we'll just say playing around with vs code. So when we added that we've got this guy here, now we can stage that command. We can say added some description, we can commit that and now we can click on these three dots. We can do a sync, a pull, or a push. Now push is going to push it up to the remote. A pull is going to pull any remote changes back down to me, which is a great idea before you start any coding when you're connected to remote. And a sync is going to do a pull and then a push for you, so you get all the changes first and then you push up yours to the remote. Since I know no one's changing this right now, I can just do a push. And it's going to run the command, you can see a little status bar, and that's good. And I don't know about you, but I like to make sure it's actually there. So let's flip open to a new browser, we'll go to my GitHub repo, and make sure you go to yours. And I can click up here on repositories and I should see new idea. Now did it get that change, yep there's a playing around with vs code. And if I go look at the commits, you can see that's where I added the description. So what's nice about this is it lets you work with a local repository and then push it right out to a remote, even if you haven't started a remote yet. If you already have an existing remote, you won't have to do those command line steps that I just did though. Because your local repositories are going to know where to go. And this doesn't just work with GitHub.com, this works with Bitbucket or any git provider like VSOnline as well. And if the company you work at has a private GitHub repository, you can also push to that remote too.
-
Git Credentials
Visual Studio code has a lot of features that allow us to see the changes, whether they're staging for new ones, unstaged changes that might be deleted or modified or just a new file all together. And all this is built right into the git viewlet. Now if you try to do that last section where we actually push out to a new git repository if you haven't set up your credentials, you're going to see a message something like this, where it's going to ask you for authentication. This is Visual Studio code recognizing that you haven't set up your credentials yet with your git remote. So you can simply just type it in here and if you need help with that you can click right on this link and that'll take it as more information about how you can connect to your remote with your credentials. And some of the cooler features are being able to show the diffs, I mean looking at our texting just side by side. We expect that out of any kind of a source control, right? So we can them side by side and see our changes, whether they've been deleted or added or replace. Or if you happen to like the inline view you can do that as well. So hopefully throughout this module you'll learn how to do all these types of different things with git in the Visual Studio code and you can become much more productive using your source control right from the tooling. And of course you can always go right back out to a like a source tree or a smart git, whatever your favorite source control tool is or right from a command line. But the nice thing is, we don't have to leave Visual Studio code for our basic and frequently used operations.
-
Debugging
Debugging
I love writing code, but sometimes I need to debug my code to make sure it's doing what I think it's doing. And one of the most powerful features in Visual Studio code is its debugger. So this module let's take a look at several ways that you can debug your code. Now you might have a simple node server to crank up, or maybe you just want to debug typescript that's been compiled to JavaScript and you have source maps. Or maybe it's just minified JavaScript. There's a lot of things that we can do baked out-of-the-box with Visual Studio code. And at this time, node server debugging is available, ASP.NET server debugging's also on its way. And you can debug this on all the platforms as well, OS X, Linux, or Windows. We'll go through how you can set up launch configurations basically just a JSON file that sets up how you want to debug and how you want it to behave. And of course we'll walk through the debugging experience, all the different keystrokes that you have the different things that we can do. And the code inspections that we can go through and attaching to processes, maybe you've already got a process running, and you just want to attach the debugger to it. And of course no debugging experience in the web would be complete without handling source maps. So we'll take a look at how we can do that too. So straighten up, get ready, and let's dive into some debugging.
-
Setting up Debugging
If you want to debug node on Windows, you're good to go out of the gate. But if you want to do it on OS X or Linux, at this time you're going to need to install Mono. The easiest way to get Mono is to use Homebrew. So if you go to this link right here at Brew.sh you can install Homebrew for OS X and you can run this command right there to install it. You just basically double click that, run that at the terminal, and you're good to go. And then you'll run brew install mono, just like that. Now I've already got it on there and it should only take a moment to download and get what you need. But once you do that if you do brew list, you should see what things you have installed. Notice Mono is one of the things that I've installed with Brew. So once you get that, you should be good to go for this module.
-
Test Driving the Debugger
When I go to buy a car I like to take it for a test drive first and see how much fun it is. And then afterwards, I'll take a look and see all the different features that it has inside, right? So let's start this module by taking our debugger for a test drive. First we'll open up the code play module right inside of Visual Studio code and then let's click on this button over on the far left, that'll open up the debug viewlet. Or I can hit Shift + Command + D. Once I do that then I can click on this little gear right up here, that's configuration, and don't worry about what popped on the right yet, we'll look at all those settings in a moment. But first we can either click this green button to start the debugger or we can hit F5, I'll hit F5. And then once that little progress bar stops you notice that the bottom status bar turned a different color for us. Now let's make this go up on half the screen and we'll go over into our browser and this particular app happens to load up on local host port 8001. So I'll launch it right there. So now I have the app running and then the debuggers on the left-hand side. Now what can we do? Well when we go to that route there it's going to show all those people. So let me pull up the routes files, it's under Source, Server, Routes, JS, and I'll pull that up in the command pallet. That was with Command + Shift + P. And once I pull that up you can see this get people function. So I'm going to put a breakpoint right there. Now I'm going to go over and navigate over to the admin pane and there's no data there. And when I go back to dashboard I should expect that to go get the people. Now when I do that, notice it spins on the right and it's waiting for a response from the server on the left, it hit my breakpoint. Now if I open up this in full pane view and I put open the sidebar, we can see it's paused on a breakpoint, we can see all the local variables in here, next request and response. And if we want to add a watch we could do that too. But for example I could pop this up here, add a watch, look at the data object that happens to be in there, and there's a people array inside of it. And I can look and see John, 25, yeah don't I wish. And then I can continue on my merry way if I'd like to. And I go back into the browser and there it is with the response. And again I come out of here and notice I get that spinner and it pops vs code to the forefront because it knows that it's being debugged. So it's all pretty easy once you get it running and there's a lot we can do inside of here. So let's start dissecting, step by step, all the things that we can do inside the debugger and we'll look at different ways you can debug with things like typescript and source maps as well.
-
Launch Configurations
Now let's take a closer look on how we got the debugging to work. So we're back inside of codeplay and if we click on this little button over here on the left that's our debug tab, with Shift + Command + D. Shows us the viewlet for debugging. When I click on that cog right up here that little wheel, I actually get two configurations. And you'll notice that this dropdown list now has a thing called launch and it has one called attach. Those map up with what's on the right-hand side for the name. So the configurations they get are different kind of debugging setups that you can run. First one's launch and then down here the second one is attach. Now you can setup multiple of these if you want, notice it's an array starting on line five. After the name the next setup in there is the type, so what kind of value could it be? Right now node and Mono are the two types. The vs code teams going to extend this in the future to support other types of debugging as well. The third one's also important, that's the program you're going to run. So running that with node, that's going to tell you okay what file am I going to run? So how did it know source, server, app, js? Well let's take a look at the package JSON file inside of our project. Down here on line 11 you can see we got src/server/app/js, that's the main file listed in package JSON. So if it sees that you have that file, it'll use that when it creates a launch configuration. If you don't, it'll default to another value. So you want to make sure you check that out. Well those first three are really important you need a name to launch something and you need the type, node. Then you need the program to kick off. After this, there's some interesting ones as well, like stop on entry. So I hover over that, you get a little hint about what this means. Automatically stop the program after launch. Now this defaults to false, but if we set that to true, it means especially her running a node server it'll stop on the first executable line of code in that node server file. So I can change that one, I can either type in true here, or I can do a Command + Shift + . and it'll toggle the value. And if there's any command line arguments to pass into that particular program, in this case appjs, I can pass them here. You get the current working directory and the run time args is particularly interesting, because by default they'll give you this ---nolazy. It doesn't mean you can't be lazy when you use vs code, no, no. What it actually means is the say settings that prevents a delayed parsing and makes sure that the breakpoints can be hit. So why is that important? Because by default when node processes this through here if you don't have the no lazy flag on there, it'll actually not process all the code that's inside your node file until it needs to on demand. It's for performance reasons. But when you're debugging, you actually want it to do that. So we set this flag to tell it, okay I'm about to debug here, make sure you process all the commands first so we have our lines matching up. Long story short, when you're running with node, this is a great flag to set for debugging. And that line 24 we've got our environment variables, you may want to pass in. And lines 26 and 28 help us deal with source maps, for example, from typescript. So if we set that to true we could automatically map from our JavaScript to our typescript so we can actually walk through our source code. We'll look deeper at typescript a little bit later in this module. So we just changed stop on entry to be true, so let's go ahead and launch this again, this time I'll hit the green button up here. And when I do that it should automatically stop on the first line of code, which it did. And then I can continue on my merry way. Now if we stop that for a moment and we flip back the configuration, now it's toggle stop on entry to the other value of false and press the Run button. Notice that when this stops and it's ready to debug, which it is, it's not actually inside the code. So why might you want to set this? This is really important when you're running a node process and you want to see the first couple of lines that are running, for example, if you want to check out how it's setting up your express server or maybe some logging or any kind of routes that you've got that are kind of that setup work before you actually hit that server from a client. On the other hand, if you wanted to set a breakpoint and routes file, you wouldn't really want to stop on entry, you want to set the breakpoint where you want it. So in this case I can go back to my routes file and you can see in here in the people I can set the breakpoint right there. And then I'll flip back into my launch JSON and this time I make sure I've got stoponentry to false. So I just want it to run right through. And I'm going to stop the debugging and then I'll start it right back up again. This time it's not stopping anywhere, right? And now we'll flip over to the browser and let's hit that right here and as soon as we did, it's actually trying to crank up the get people. So now it doesn't actually go into debug mode until something tried to instigate that and hit that breakpoint. Now I'll stop the debugger and now let's go back into the launch JSON file. Let's say you didn't have these settings here and you wanted to find out what was available. Because we've got the JSON schemas we can just enter a new line in here and do a Ctrl + Space and you can see all the different kind of properties that you have. And we've gone through all of these here before. Now that we've seen how to setup debugging, let's walk through the different keystrokes that are really important and what you can do while you're debugging.
-
Debugging Keybindings
We're about to dive into debugging, so it's important to know the different keystrokes that can help you out. The first one is F5, that's going to help you run your debugger, which we saw, and it'll also pause the debugger. And if you set a breakpoint somewhere inside the code it'll also run to the cursor. And then Shift + F5's going to let you stop the debugger when you need to. F10, well that's going to help you step over code and then it's got a brother here called F11 who's going to let you step into code. So stepping over it will step over functions, step 11 will step into the function that you're on. Then there's a Shift + F11 which'll let you step out of code. These are all pretty standard debugging features that you get out of any large IDE that does debugging. So it's great to see them in header like Visual Studio code. Now we also have F9, which lets you toggle breakpoints on or off. You can also disable them too if you want to and then there's this little green circular arrow which lets you restart the debugging. So let's say you're debugging and you actually want to stop it and then restart it, you don't have to Shift + F5 and then F5 you could just click the restart the button. Unfortunately there's no key binding to that directly yet.
-
Debugging Walk-through with Keybindings
Well let's take a walk through the debugger and this time so we can actually step through all the commands let's set the stop on entry to true. And let's go ahead and run hit, we'll hit an F5 right now. Notice it's going to show you the toolbar at the top for the debugging. And over on the left hand side we see all of our panels inside the viewlet. So we said we could do F5 to start it, notice we automatically stopped on the first line because we told it to. Now if I click on this green button, it'll continue or I could click F5 again, which will just continue on. And there we go, it just continued. Notice it turn into a pause button up top and I lost my little breakpoint. So now if we want to stop the debugger we just hit Shift + F5 and that'll stop it. Now hit F5 again, starts it right back up, it's going to break in the first line. I can also stop it by clicking on the red button. So if you don't remember these keystrokes, all of them, or at least most of them, have a little tool tip right next to them showing you what those commands are. So what are these other guys in here? This is the F10, F11 crew, where this on right here is a step over, that's F10, we'll click on that one now. So we're going one line at a time. And we just click over each of these guys. Well what if we set a breakpoint down here, we could do that, and now we could hit the green button or F5 and it'll continue right to that point. Notice the call stack changes each time it tells you what line of code it's on. Now let's keep stepping over a few lines we'll get down to line number 19 and on here let's say we decided we wanted to step into or hit F11. And when we do that notice we're actually diving into another module. We could have stepped over it and it would have stayed inside of appjs, but now we're actually inside of module js. So let me show you something kind of cool. Remember we can do different panels? If I do Command + 2 here and open up the second panel, go back to Command 1, this should highlight the first panel. And now I do Command + P twice to get the app js, notice I'm looking at both files on the left is the original file where I left off down here on line 19. And then I jumped over now into here, on line 384 inside modulejs. So let me just step over and then when it's done with this, worshtipop, right back on the left there, because that's where it left off. So I can step over and step into and I can also step out if I wanted to. So let's go ahead and stop the debugger and try this again. Now let's relaunch our debugger, we're walking through here and notice that we can set multiple breakpoints as well. And every time I set a breakpoint, notice that the breakpoint on the left-hand side are growing and growing and growing. And maybe I don't always want all those, so what I can do is I can disable some. I might want to keep them for later, so I just click on this side to disable them. Now you can see the kind of just hollowed out red circles. So now if I press Run or F5, it'll stop at the first one that's been enabled. And you can also delete these just by hitting the X's over here too. Well the last trick is let's say I made a code change here, well when you make a code change you're not actually getting hot changes and replacements. Meaning it doesn't actually see those changes, you just get to change them as you go. Like maybe I don't want to say about to crank up node, I'm going to say, getting ready. So I can type right there, which is great. And it doesn't prevent you from typing in your debugging but it's not going to see that code change. So what I could do is come up here the upper left, and click that little green circular arrow and restart it. And it restarts the server back in the first line of code, come on back down, and now it sees those changes. So these are just some of the ways you can use the keystrokes to help you debug.
-
Attaching the Debugger
Well launching into the debugger is great, but sometimes we need to be able to attach to an existing process. Remember that launch JSON file? If you're not sure how to get to that back in the debug you click on the little wheel right there. And now we can take a look at this name, the second configuration called attach. That comes out-of-the-box, we can name it anything we'd like actually. And then it's going to run node and it's going attach to this particular address on this port. So we could come back in here now and run a command, actually run something like node ---debug --brk. And then run our file. So that debug break means break on the first line, sound familiar? Yeah, so let's open up our debugging here and I've removed all the breakpoints. If you haven't done so please click the X right there it'll get rid of them. And let's go set one inside of our routes file too. So let's go back into routes and we'll set a breakpoint in the get people on line 14. And now notice that's the only breakpoint we have. So we've now run this code on the right in the terminal, it says the debugger's listening on that port, that's the one we're going to be attaching to. Now we click this green button over here and notice it stops in the first line of code. Now if I let that run through we should be good to go. And if I open up the browser and I hit local host 8001, let's move that over on the right-hand side, when I do that notice it's waiting because on the left-hand side it hit the breakpoint that I happen to set in routes as well. So it's just another way that we can actually run our debugger. So I'll continue through here and then I can close debugger out and we are all set. One handy tip, you want to make sure you check your terminal, because if it's still running sometimes you want to Ctrl + C to get out of there. Just to make sure the process is killed.
-
Debug Experience
We just saw how you can walk to the code in debugging, but what else can we do? So let's go back and clear all of our breakpoints, hit the X if you haven't done so in the bottom left. And this time let's launch the server and we'll make sure it's set to stop on entry. And when that launches up, we've got a breakpoint right here. Notice on the left we have four different panes we've got variables, watch, call stack, and breakpoints. So what's inside of variables is the locals and any globals. So we can see any variables that we might have. Now the locals are the one that's most often useful, we can see things here like the dirname that we set. And you see the big long path name. And then the file name. You can also hover over different things inside of the code. For example, I can see dirname right down there and I can hover over it and you're going to see a little glimpse of what that code looks like. And of course you can explore all the locals that you have inside of here looking through module and children and anything else you might want to look at. So beyond the variables you can also look at watches, so I set up a watch called data earlier and it's not available in this scope, so we can clear that one out. We can also highlight a variable, right-click, and we can say add to watch. And there we get one right over there. And it's not set yet, so it's undefined. Now if we walk through here it should change as it evaluates. So we'll walk through once, twice, three times, and there we go, there's app. Now we can also set longer things like this, we could check out process port. So let's copy that, come over here, we can right-click and add an expression. You can enter that into here and right now it's set to undefined. But now let's just go ahead and grab process, we'll right-click, and we'll add that as a watch. Things there as a process, now we can go look for env inside of here and it is alphabetical. There's env, and on there do we have anything called port yet? No we don't, so that is true and that's accurate. Well just for grands let's go ahead and add the local variable called port and we'll add that to a watch as well. And if it gets kind of crazy and crowded in here, you can come up here and you can delete the watches. Or you can collapse them all, which is often helpful. And now let's walk through and as we click through here you'll see the port value should change from undefined 8001. So watches are very helpful, because you can do lots of things like checking out the values as you go. Next up let's take a look at the call stack. Here we can see the calls that are flying through. And this becomes even more helpful as you dive into code. So remember earlier, down on line 19, we dove inside of a require. Let's do that again. Set a breakpoint here, we'll click on the green button, run data there. Now step into, which is also F11, and we do that, you can see now we jumped into this require statement inside this module js. And if we step back out, right here, we jump back outside and we're back inside of our anonymous function. Then of course the bottom pane allows us to see all the break points. So here we can see we can break on all exceptions or unquote exceptions. And any specific breakpoints that we happen to have set. And then we can disable those. And anytime you want to toggle a breakpoint, you can just highlight a line, like here on 21, and hit the F9 key. And then I'll toggle a breakpoint right there on or off. Now let's stop the debugger for a moment let's set up a different scenario where we actually want to walk through the different call stacks and different files. So I'll hit Command + 2, open a second panel, and let's go ahead and hit Command + P and we'll go to the routes file. And over here we'll set that breakpoint again back on line 14. So now let's go ahead and launch the server and it's going to stop on the first line of code here on use strict. And we'll let it go through. It's going to stop again on the API where it sets up and defines the routes. Before we set anything here, let's set a breakpoint right there on line 5. Now when I run through it's going to hit line 5 right there, so we can go check out the call stack. And now we can see it's jumping in there, pause on a breakpoint, in our anonymous function. And if we step through here, watch what happens. We're stepping through one at a time, we set up our router, and then it jumps over those because those aren't executing the functions, those are just defining the functions. So now we can let it continue. We never hit that statement on line 14 of routes. But if you open up our browser and now we browse to the site, and we hit that, by default it's going to go ahead and try to get the routes of getting the people and it stops right on that breakpoint on line 14. Now we can see the call stack over here and what it was doing. So right there it's going to go in line 14, that's where we had the breakpoint. And then we can see the internal code inside of express that was running to get there, which is awfully helpful when you're trying to debug. And then we can see all the code running throughout. So all this is inside of express and then we jump back out again. Now we're inside the router for express and you're just slowly stepping out of where all the code is. And we can scroll all the way to the bottom, to the inner most code it runs. So it's kind of neat to see where is all this happening from? And now we can see there's the get people at the end of the stack. So at this point we can interrogate all the properties, like there is a request, a response, and the next call. So what is data look like in this case? And it's got an object called people, it happens to have an array of eight things in it. And sometimes when you hover you can't see all the details, so that's when you go back over into your watch. And now here we could actually click on a watch and we could say alright let's watch that data parameter. There's object data, there's people, there's our array, and we get all the details in here. There's John Papa and let's click on a before. And there's Ella Jobs. But do we have to use a watch to do that? No, we could also click on the variables up here. We can see the next request, response, and this. And then inside the closer what do we have? We've got data right there. And then we've got this 404 object. So you can look at all sorts of different values, both by hovering and a combination of the variables. And then also the watches. So hopefully this gives you an idea of how you can walk through your code and see what's happening inside of node pretty easily.
-
TypeScript Debugging and Source Maps
So let's take a look at how we can debug some typescript code. Let's open up the ts play project and you'll notice inside of our server folder we have some typescript and some JavaScript. Now the typescripts is what we've been writing in for this project it's all got typescript code. Here you can see the type of this app is actually express.express on line 14. But let's say we want to delete all the JavaScript and the map files, just to start things out. So let's go ahead and right-click on server and we'll reveal in finder. Or we could open that explorer if you're on Windows and I'm just going to go through and click on all the js and js map files, there aren't too many of them. And then I'm going to delete those. And then I'm going to also go inside the utilities folder and delete the not found js and not found map. So why do we do that? Well it's because we got a bunch of typescript and we want to see if we can debug it straight up without any JavaScript, which as you might have guessed isn't going to work so great, but let's give it a shot. So now let's go to the debug and notice we don't have any configurations, we'll click on the little wheel up here and the program on line 12 is set to src/server/app/ts. Where did that come from? Well left from the pack is JSON, we do Command + P, step into package JSON if there's a main file, it grabs that right from here. So that's pretty cool. So I'll go back into launch JSON, now we see we're running node, we're going to run and launch that typescript file. Let's have the stop on entry to true just so they can see if it works. And then down here we still got our no lazy and everything else is pretty much the same. Let's go ahead and press debug. Now if it works we can see a debug, but instead it says it can't launch the program enabling source maps might help. Well that's good, there's a key right there. Notice on line 26 we have source maps set to false. Why do we need source maps in this case? Because we don't have typescript compiled over to JavaScript, first of all, and if we did, it can't really execute the typescript, it's got to compile to JavaScript. And then we want to use a source maps and map it. So one step at a time, right? Let's go ahead and set the source maps from false to true and now let's try to debug it. Now we hit the debugger and now it says hey I can't launch the program setting the outdir attribute might help. Well in this case it's not actually going to help, it's giving us a hint though. It's telling us the outdir was supposed to point to the generated code. Generating code is the JavaScript that comes from the typescript. Well it can't find it. So it's saying, hey maybe you go to point the outdir to wherever it's located. Well remember we just deleted all the JavaScript, so what do we do? Well one thing we can do is we can set up the typescript compiler to automatically compile over to JavaScript. Notice over here on the left we've got app ts and data ts and routes ts, but we don't have the JavaScript files. So let's go over into our command prompt, we'll clear things out a little bit. And we can run the typescript compiler. But first to make this a little bit easier let's look inside of this special file I've got inside my server folder called tsconfig.json. That's the typescript configuration. Here's a bunch of options and saying every time I compile with typescript I want to use these options. I want to turn on source maps. Please generate those map files. I want to target ES5 as opposed to like ES3 or 6. Let's remove any comments and not allow any implicit anys in there and we'll use the common js format. So because I have that file right here, when I go back out to terminal I can run tsc, tell it to look in a folder, it's under source, and then server. And then it's going to put the output right in place and it's going to read that ts config for how to actually do the compilation. So when I do that it completed and notice that we're on the left I've got my appjs and my appjs map back. So now if flip back into code, and we go back to debug, and we launch up the debugger, now we can see it's actually stepping in one line at a time. So there are a couple things we had to do to make that happen. First, let's just go back and take a look inside launch JSON make sure our program is set to the ts file. We stopped on entry so we could actually see it happen. And now the source maps had to be true. And once we set the sort maps to true we could either point to the output directory of where it's located or leave it as null, which means it's all in place, meaning it's side by side with the appropriate ts file. Which then meant I had to go compile my typescript which is use the typescript command line for. So now I can walk through the lines one by one and notice I'm walking through the typescript code. So in here I can hover over variables and I can see what they're going to be, if there's any values for them or I can check them out over here in the locals. I can have watches again. I can check out my call stack, of course it all sorts of breakpoints. So let's run this right to the next breakpoint. And when I do that you'll notice, if we get rid of the watches, up here in the locals you've got your app and your body parser and your environments all that stuff's set. And then anything down here that's been set, like app, or port, or environment, which is still undefined, we'll actually be able to hover over. Now what would you do if you didn't have that ts config file that we just looked at a moment ago? Well you might have to set all those kind of flags, for example you could use tsc ---source map or you could use ---outdir for the output directory. You could set all these different things or ---target or ---module. So it's a lot easier just to create a ts config JSON file isn't it? And then we just settle up in here and then all I have to do is go back to my terminal and I just run tsc-p, for where am I going to put that project. And that's source server, so it knows where to look for everything. Alright, so we just debugged out typescript code what if we actually wanted to debug the JavaScript that's in this project now that's it all here? Well we can do that too, so let's go back into our launch JSON and now let's change the program from ts to js. And down here for source maps let's turn that back to false, because there's not going to be any because that is the source. Now we'll leave the name alone, because it really doesn't matter what you call that. Now we go back to the debugger, let's go ahead and launch it. And notice now we're on the first line of the JavaScript file. So this is the compiled JavaScript that came out of the typescript and we're actually debugging through that. So you can choose either/or, it's more helpful in this case to go through the typescript because that's the actual code that we're writing. And the JavaScript's just what ends up being compiled or transpiled, if you will, out of the typescript. So let's go back and reset that we go back to source maps true and point to our ts. And let's hit this from a browser. So we'll run this again in the debugger, it launched it up, we'll let it continue all the way through. And let's go ahead and go through all of our breakpoints. We'll get rid of that one. Now let's open up that routes file again. This time we're going to hit routes.ts. And we'll go down to the people right there on line 22. And we set our breakpoint, so now let's go ahead and do side by side, we'll open up the browser. Let's go ahead and refresh this page. And when we do that notice we've actually waited in the browser on the right and on the left we can see the breakpoint right here. We can make that bigger. And now we can see the data again, so we're back in here. So we're on line 22 and we are paused. So I can see we got the request and the response and we can come back over here and take a look at any of these local variables. And then we can step through and if we'd like we can continue all the way through and then we can flip back to the browser and it should have gotten the data back by now. There we go. So what makes all this possible is the source maps that it generates from the typescript compiler and then Visual Studio code kind of connecting the dots for us. This makes it super simple to use typescript on the server and debug it easily in vs code.
-
Server Debugging
We just saw how we could walk through and debug all the code on the server using these keystrokes here. But don't worry if you forget these, you can always look at the debug toolbar as well or the debug viewlet. Now this helps us debug on the server and we can use code inspections to look at those values while we're debugging. For example while we're hanging out on the server we might be inside of JavaScript file like this we can pause on a breakpoint and check some watches out, like we see over here on the left-hand side. So we've got some like local and global variables up here in any closures would be there as well. Or we can check out some watches that manually add. We could always look at the call stack as well and of course set a lot of breakpoints. And I can only imagine there'd be more features coming here as well. Because a debugger really is one of the highlights of vs code. So let's say you're not in JavaScript, but you are in typescript or minified JavaScript. You can actually use source maps in vs code to do your debugging too. So what would that look like? Well that's when you walk through like a typescript file, like this right here, notice it's app.ts. And then we're using source maps to walk through the code. And yes vs code is great for debugging all the server side code that we have. I still used a browser, Chrome is my preference, to actually do all the client side debugging. While some IDE's are powerful enough to handle client side debugging, none of them are quite frankly are nearly as good as using just a plain old browser. So I use vs code for debugging all my server side code and then I use the browser to debug my client side code. So in recap, the five most important debugging features that I'd like to point out are making sure you understand how to launch the debugger itself. So how you can actually run your code and launch the debugger at the same time, is in the launch JSON. But it's also handy to know how to attach an existing process, so attaching is key as well. Both those are handled from the same launch JSON or by hitting that little wheel up in the debug viewlet. Sometimes I need to be able to debug and stop soon as it comes on an entry, so I like to set that to make sure I can check all those initial values. And of course all the different inspecting options, kind of cheating here, because that's many different features. Those are the globals and the closures and the variables and the watches and the breakpoints and the call stack. And as you might have guessed, I kind of enjoy using typescript and ES6 so being able to check out source maps and debug those is really key for me inside of ES code when I debugging. And this is an area the vs code team put a lot of time into and they're still doing a lot of investments, so I expect a lot more features to becoming for the debugger.
-
Integrating Code with External Tools via Tasks
Tasks
Having a build processor automating different kinds of tasks like transpiling code from Less to CSS or typescript over to JavaScript. It's just kind of par for the course for working in the web world. So it can be helpful when Visual Studio code can integrate with these task runners in a lose way that you can pick which one you want to use. In this module we'll take a look at how you can integrate with task runners from Visual Studio code. So in this module we'll take a look at how vs code can leverage some of those task runners and the different tools. Because you might not have a task runner like gulp, but you might just want to make sure you can transpile your ES6 code using babel. We can do that. So we'll demonstrate how to do this by connecting to different tasks with the task JSON file. We'll take a look at task JSON and show how you can configure it to transpile with babel or typescript too. And sometimes we might want to pick up any problems that these things detect, like js int and any issues it has. And we can add those right to the warnings list right inside of ES code, that's using something called problem matchers. Vs code can detect certain kinds of task runners, like gulp, grunt, and jake, so if you have one of those files in your project, it'll automatically pick up those tasks by default and that's pretty cool. It makes it easy to run them right from the command pallet. So we've got a lot to cover, let's dig in and show how you can use the tasks.
-
Creating a Babel Transpiling Task
Let's open up our ES6 play sample and let's add a task that'll automatically transpile our JavaScript what we're seeing right here, over into ECMAScript5 using babel. Okay so for starters let's delete the dist folder, that's where we're going to put our output. So we're going to take this autojs, for example, and we're going to transpile it into ES5. Well let's go ahead and get rid of the dist folder, we'll right-click that, and we'll click on delete. Yep we're going to move that to the front of trash, now all we have is our source. Next step, let's go into the command pallet Command + Shift + P, and I'll just type in task. And you can see there's a variety of different things we can do here. The one we want is configuring the task runner. So we'll select that. Now when it comes out-of-the-box the first thing you'll notice in this project is that it's going to give you a gulp command. The reason it sees this is it knows that we've got this gulp file down here in the project, so it's seeing that we're already using gulp. But let's do something a little tricky here. Let's go ahead and delete this settings folder up there that'll get rid of the tasks. And now down here inside of our gulp file I don't want to delete that, but let's just hit Enter on there. We'll rename it and we'll just put an X in front of that. That way it's not going to detect the gulp file, because that's a tradition with gulp or grunt files, they look for a file called gulp file or grunt file. So now let's go back into the command pallet and type task and we'll hit configure task runner. Notice this time we got a different task JSON created inside of the .settings folder. This is the default the default file that you'll get when it can't detect what you're using for a task runner or if you're not using task runner at all. So here it gives you some samples, so here's a command tsc that'll run in the shell. And then in the output it's silent and it's only going to show you the output if an error happens. And it would run against this particular file. Well that's not going to help us much so we're going to comment out this section here by hitting Command + /. But you can look through here and see a bunch of other samples, there's one for tsc here's one for gulp. And if you scroll down you'll see even more, one for Jake, another task runner, MSBuild. So let's start from scratch, let's just delete everything that's in here. And now let's create the JSON object and now you might be saying wow it's a blank ng JSON file what do I do? Well we're going to use our IntelliSense, the Ctrl + Space. First we're going to need the version and the version's always starting out right now at 010. Then we want to put a command in here. So we're going to type command in now this command's going to be a little bit long, we want to run babel so we can transpile our JavaScript. So we need to have a command to go run babel against. Now the problem is we don't have babel installed yet do we? So let's go do that first because we're going to need babel to do our transpilation. So let's pop over to terminal and make sure we get this. We do npm install babel and now I'm going to do ---save-dev, like this. That's going to go grab babel and it's going to put it in my node modules folder of this project. We need this so we can do our local transpilation. Now once that's in there, we'll be able to see that inside of our package JSON file, right down here on line 20. And inside my node modules folder we'll see a babel folder. Now that we know we have babel installed, let's come back into our tasks file and the command I'm going to run is inside of that node modules babel folder. So first we're going to tell it we want to go to the workspace route, this is a special reserve replacement variable that gets us right to our workspace. And then we want to go into the node modules folder and then it was in the .bin folder .babel. So just to make sure we got this right let's go look. Node modules and then inside of bin and there's babel. So that'll run that command, but where is it going to run that command? So we want it to run in the shell. So this is going to be a shell command, set that to true. And now we have to set our tasks up. And obviously you can have more than one task. And the first one we're going to have to give this a set of arguments. And we'll put all these on one line just to make it a little easier to read quickly. So the first arguments going to be, okay what folder do you want to put these in? All you sources in the js folder. And now I need to tell it what the output directory is. And that's going to be dist and I'd also like it to create source maps. Alright so that's going to be the command line, basically that would be the same thing as if I went to the command line and typed in babel and then I told it, okay go to js and then do the outputdir to be dist and then ---source maps. So you get the idea. If I ran that from the command line that's what I'm getting, so those are the arguments. Now we're going to type in a task name, because you have to call it something. So let's call this babel. Could be named anything, it could be named Fred. And then it's just going to be the build command, we could say true, so that way if you hit the build command key inside of the command pallet, it would run this. You don't have to do that, but it's nice to have one particular command that'll do that for you. Alright so now that that's set up, we should be able to run our tasks, but let's check this out first. Let's go ahead and open up the autos file and this is the file that we're going to transpile using babel. And let's also keep an eye out, right over here, because that dist folder should appear when I run this. So now let's go back to the command pallet, we'll type in task, run task, and notice I have assigned my own shortcut key to this, that doesn't come by default. And we type in task up there, it sees there's something called babel. There's another way to get here too, so let's hit Escape first. You go to the command pallet, get rid of that little caret, and just type in task (Space) and it sees that babel is there. So I can run that and you can see the output on the right-hand side. And on the left-hand side, low and behold there's our dist folder. If I open that up, there we go. So it says it compiled all four of these into those four files. Let's go ahead and open up autosjs in the right-hand side and there we can see it.
-
Watching with Babel
Well this is great for one time compilation but what if I want to make sure I add something else that actually gets transpiled? For example I create a get foo function over here and I have returned the value of foo. Nothing's happening on the right-hand side. I could rerun the task, but kind of defeats the purpose if I want to have it do it on the fly. So a couple ways you can get back into task JSON to fix this, we can go and click on the file over here as one of them. Then I'm going to go over and hit this little X and get rid of him. Now we can copy and paste this task or we can hit the command + Option or Alt down arrow. And I put comma in-between there, make sure you do that. Now for the second one let's first change the name, this one's going to be babel watch. We want it to watch the files. It's going to be the same, except we want to have an additional flag in here for watching. And it's not going to have a build command be the case. So that's going to be false. So now let's go back and take a look at our autosjs, go up to the command up here. We'll type in autos we'll look at that one in this side and then we'll open a second panel with command 2. And let's go ahead and click on the autosjs dist, just show you a different way to get there. Now notice get foo is not on the right-hand side. But if we go back to the our command pallet and we type in task, now we'll see a new task called babel watch. When we do that it's running and transpiling and you'll notice in the bottom left-hand corner that little spinning line. That line is telling you something is running inside of vs code it's got a task that's running. It happens to be our watcher. So let's go ahead and put a third panel up and we'll go back to the second panel by putting our cursor in there. And we'll click on the autosjs and now we can see here the right-hand side we've got our output, but on the left we've got our ES6 and on the middle we've got our ES5 and notice it was transpiled. Let's change get foo to say get bar and a couple things are going to happen as this is running. Notice that as I was typing and I pause, the watcher was picking up the file change in the right-hand side of the output and was showing a transpilation. It told you which file it transpiled and in the middle pane we now see get bar. So every time we make a change now inside of our editor, we don't need to look at the output to see this, we can actually see it happening on the right-hand side. So now I can type in another one called get foo again and this time we'll say okay the real foo. Down on the right-hand side we're going to see that function actually appears now. So now we've created a watcher. And keep in mind we're not using any task automation, such as gulp or jake or grunt, we're just doing this using the plain old babel transpiler. So what happens if you want to kill this task? Well here's another command you can learn go up to your command pallet Command + Shift + P for me, let's type in terminate or just term. And you'll see there's a command stroke that I've assigned to terminate the running task. It doesn't come out-of-the-box, but this is a really handy one so I like to apply this to a keyboard setting. So you can either use a keyboard keystroke, like I set up, or you can just type this in and then hit the Enter key. And notice when I do this the bottom left-hand corner that line will stop spinning. So just a quick refresher on that keyboard keystroke, we go up under the File menu, go over to Code, under Preferences, Keyboard shortcuts. And we'll get rid of the sidebar quickly. And you'll notice on the right-hand side I've got a couple custom keystrokes. The first one I assigned is Shift + Command + K, which is going to run a task for me. And then Shift + Command + X will terminate a task. So let's get rid of those for a moment and remember how we can do this. Now that I have those keystrokes setup, I can ope up my autos in the left and the right and I can do Command + Shift + K to run a task. I hit babel watch and it's running over there. Now I don't really want to see that output so I'm going to hit Command + P and I'm going to type in autos and go down to the dist. Now I notice it's running, but let's say I wanted it to stop running. I can now hit Command + Shift + X and you'll notice the spinning line, in the bottom left-hand corner, went away. So let's take a look at that task JSON one more time. Up here we've got two tasks, both set up to use the same shell command. We're saying go into the node modules folder for babel and run this command babel. And then when you run this task, here it's going to run babel with these particular parameters. And then we run this task and run babel with those parameters. The first one just runs at one time, the second one runs it as a watcher. Now of course to do this you'd have to npm install babel first, because whatever you're going to run you actually have to have in your machine. But the cool thing about this is, this means you can run anything from the shell. So you can really go out there and run typescript compiler or js hint or whatever your favorite commands are. You could even run command line things that are built into node. So this doesn't tie you down to any existing task runners, it means you can run anything that ends up being runnable from the command line. So this is great because we don't know what's going to be invented down the road for JavaScript, so now we had the ability to run any command we want right from the tool.
-
Transpiling TypeScript
We just took a ride with babel, so let's go take a tour with typescript. Now we'll open up the ts play project and notice this one has nothing in the .settings folder for tasks, it just has a launch JSON, which we're using for debugging earlier. He also has a gulp file, so let's go again down here to the gulp file and we'll put an X in front of that. Remember if you want to use those gulp files later, we'll want to get rid of that X. And now let's create a task file for this one. So we'll go to our command pallet again and we'll type configure task runner right there. And now notice is giving us a default tsc, right up top, this is that default file. We happen to want typescript, so that's going to work for us. And we're going to configure this a little bit. I'm going to delete everything below here just because a lot of comments, might be helpful for later, but for right now that's just a lot of noise. And we'll get rid of everything up above. So here we've got our version, we want it to run tsc, that's our typescript compiler. Now notice it's not actually a path to the typescript compiler, it's running it tsc assuming that it's installed globally, that's what the comment above is telling us. And if we haven't done that, you want to make sure you run npm install --g typescript. It is a shell command indeed and we're going to set the show output to silent again to only show the output if there's an issue. Now we don't actually want to run anything called hello world.ts, instead we're going to run against our code. And we've got something down here called a problem matcher. We'll talk about that in just a moment. So let's change up this path, because we're not going to actually going to use that to just compile the one file. We'll have to compile all the projects, basically just this one project here with all the files inside of it starting at src/client. So we can see over here there's source and then a client folder. And inside of there we can see a ts and a js file. Just to see if this is working or not let's go ahead and delete this app module js. That's a transpiled file from this typescript file right here. So now let's go back and attach JSON and if we run this, we should be good to go as long as we've installed, npm installed, -g typescript. So now we can run our task and go over to the command pallet, type in task, and notice it says tsc right there. So if we do that, we should see the little spinning wheel in the bottom left-hand corner, then it'll disappear. And then we can see this js file the transpiled output once again. And it's doing this for all the files underneath the client folder. So you can see how simple it is to hook into things like babel or typescript or anything else you need to, to run from the command line. And as a refresher, notice we didn't have to put a path up here to the typescript command line, because that's installed globally. But with babel we did. That's because we chose with babel to install it locally. If we had installed babel globally with the --g, we wouldn't have needed that whole path, we'd of just said command was babel. If you wanted to create a watcher, like we did for babel, it also has a command line argument of --w, that's typescripts. So now we can run the same command, in this case we'll run tsc again. And notice in the bottom left-hand corner you can see that little bar flipping around. It's actually watching files now, so they go inside of this file and open the other one up on the right-hand side and I did that by holding the Command key while I clicked on that one. And I come up here and I could, let's say, add something else in here like var X = 1. And when I compile that, you'll notice it appears in the right-hand side and it's still running. And if I want to kill that, I can use the command pallet or I can set up that keyword shortcut like I did the Command + Shift + X, with are the command pallet this time, type in terminate and bam it stopped. And that's how easy it is to set up a task.
-
OS Specific Commands
Before we go too much further, let's make sure we understand the differences between the different operating systems. So let's say we're running on OS X, like I am here, and the command may not necessarily be just tsc. Maybe on Windows I want something slightly different. So what I could do is come down here and there's actually a windows section, we can type in on Windows, but on a run. I want this one to have a command of what, maybe it's tsc.exe. And as you might imagine, there's also things in here for Linux, if you have Linux specific commands. And if you have OS X specific commands you can put those here too. So if you have to run something slightly differently, by all means, feel free to put those in those sections. And if you want to know what goes in those sections, just come inside of them and hit Ctrl + Space and you'll see all different kind of arguments you can add. This is just a nice and nested way to set up very specific kind of tasks and the commands that you might want to run based upon the OS. So if you might have a team that's working on Windows and OS X, like mine is, and therefore we can run the same commands just have a different mappings in here. For example, maybe I want to run a command on Windows and I have to find node, so I'll have to go to C and then Program files and then find node. And obviously that's going to depend on where I've actually located my commands. And then on Linux I might have a command in here and saying you know what for node down here it's actually located at user bin. So we can set up those commands very easily using this kind of mapping. So if we're using a different OS you might want to set these up. And then all the other settings are doing, you might want to put those inside of those OS specific commands.
-
Problem Matchers
Remember that problem matcher at the bottom? Well that $tsc is saying go ahead and any problems that the typescript compiler notifies us about, grab those, using a regular expression that's prebuilt here, and pull those into the errors and warnings of vs code. So do you to know regex to use these? Well the good news is there's a bunch of them that we get free. So let's flip over to the website, the documentation, under tasks, up here at the top. And in the first section they have is about processing output with problem matchers. Now this list is always growing, but out-of-the-box we get typescript, js hint, ES lint, C#, and the Less. And you can also define your own problem matchers as well if you come down to the bottom down here. Defining a problem matcher on the right and it actually shows you how you can set up patterns using regular expressions to find out where's the file name, the line number, the column, the severity, and the message. And that will map out how it basically parses the output from whatever you're using, whatever tool that is, and then pull that into vs code. So for us, for any of those prebuilt ones, we just had to say which problem matcher we want. And yes you can have more than one. And we'll show you how to do that in the next section.
-
Automatic Gulp Detection
So let's say that you're using something like jake or grunt or gulp, how might that work? Well let's pretend we didn't have this task JSON first, so let's go up there and let's not actually delete it, let's just change that name to a tsc.task.json. So we can kind of hang onto that, but it's not going to run as task JSON. Now let's go back to the bottom, remember we had basically renamed out gulp file? We called it X gulp file. Let's name that back to gulp file. So if we have a project, like this, tsc play, that's already got a gulp file in it, what happens when you start running our tasks? So if we go back to the command pallet and we get rid of that caret and we type in task (Space). Notice it's searching and it found a bunch of other commands, auto test, build, bump, clean. There's a whole bunch of them in here. In fact I've got one in here called vet that I could run to check my code and vet my code out or tsc. So what are these things? Well it's actually scanning our gulp file, it sees that I've got a gulp file in here, I didn't already have a task JSON, that was the first step. It sees that I have a gulp file, that's the second step says, hey you know what, I can just read those out-of-the-box. So when we type task we can see one called bump, clean, and even tsc, let's go find those in our gulp file. There's our tsc commands, let's go look for bump. And there's one for bump, so it's scanning that file so we can those. Now for example I can come up here and I can run tsc and then over on the output it's going to run my tsc, which happens to run the client and the server. And it's going to compile all of my typescript. Now the difference between what we do here and we did before is that now in this case, I've got a gulp file that's got a custom way to run my typescript compiler. And it's got a bunch of other tasks that I can do too. So not only can I run typescript, and I can watcher's for it as well, but I can run things like js hint or I can do a serve or I can use browser sync to load my browser and then use sockets to inject CSS as it changes. So when you get more advanced into things like gulp or grunt or jake, you can run those right out-of-the-box. Well let's clear out the output and then let's go ahead and run this serve development task right there. We'll run that up and what this lets us do is it runs all through the output puts my program together, and then launches it right in the browser. So you can see how easy it is to run a command from gulp using vs code without even having to go to terminal, because it just launches it for you.
-
Custom Tasks with Gulp
Let's flip back over to our code play project that's running JavaScript or ES5. And this one has a gulp file in it and node task JSON. So if I go back up to the command pallet and I type in task (space) it's going to auto scan and find those same kinds of commands. So I could run a command there and see any output that it might have. Now what if I wanted to run those commands as in other particular patterns? Maybe I want to pick up any js hint issues that they're finding. So what I could do is I could go back up into here, in my command pallet, and I could configure my task runner. And that's going to create a task JSON that has a command of gulp. So gulp was installed globally here and that assumes that you've got npm installed as g gulp. It's a shell command. And then we're going to set up a task called build it gives you one out-of-the-box and one called test. Now that's great, but let's just take a look real quick when we run our tasks to see what shows up. We've got a build and a test there and if I go to my task runner and I type in that, you're going to see the build there, but you're going to see all the ones in the gulp file in here too. So it's kind of combining those two or a union of them. So what if I wanted to run a task called vet? Let's go back into the gulp file and take a look at that. So here I've got a task, I'm going to call it vet, right here on line 36 and it's basically run through js hint and js cs and use the report called js in stylish to figure out what kind of issues do I have in my code. So I can run that. Let's run that up here task vet, and then any issues I have will show up in the output on the right. Well let's go ahead and make an issue. We'll go into the pallet, and we'll type in dashboard and go into a controller. And let's just remove a semicolon just for errand here. And the we'll run that command again I'm doing Command + Shift + K for me or you can just go to the pallet and type task (space) typing in vet. And then on the right hand side you're going to see the issue. Now wouldn't it be great if we could take that data that's in the right-hand side and put that into our errors and warnings. Well we can. And some of these sayings out-of-the-box are just going to get picked up, because the editor is trying to show you that you've got a problem right there. But, for other things, it's not going to always know what those particular issues are. So whenever you're running a third-party tool, you can grab those using problem matchers and pull them in. So what is he talking about? Let's take a look here. If we go back inside of my task JSON, see these problem watchers we have down here for this particular task? So inside the task JSON let's set up a task and we're going to call it vet to match the one that's in the gulp file. And then we're going to have it run and use the problem matcher for js hint. And also one for js hint stylish, because that's the reporter we're using with it inside of our gulp file. So now when I run my output, I can say task vet, this one's actually going to look at the task JSON one, which will then run the gulp one. In this case it's going to grab that data and if I go back into that file we're going to get an additional error warning here saying we've got a missing semicolon. And notice that's the same command there and it's online 16, column 28. So that particular problem matcher is finding all this information, using regular expressions, using the reporter as its guide to figure out how do I get that data and shove inside of the errors and warnings? So we might not want to override the existing gulp tasks, we want to create our own with a couple different nuances. So I can create a task called vet2, which doesn't match anything in my gulp file, so I have to tell it where to run it in gulp. The arg I'm going to pass is vet and I have to add an additional parameter here. In this one I'm going to say suppress the task name. And then we're going to set that true. What that means is, this thing here, this task name on line 10, we're going to suppress that, it's not going to be passed along because there is no such thing as vet 2 inside of the gulp file. Instead, we're going to tell it to run gulp, vet, that's the arg. And then we'll use these particular problem matchers. So now with Command + K we can type in vet and you'll see vet and vet 2. Vet's the original one in the gulp file, while vet 2 is the one I just defined here. Which basically relays to vet 2. And when we run that, it's going to run that command and get the same input. And that input will be used by scanning this output here using a rejex with the problem matcher. And then it can go put it inside of that file. So we can see that we have those errors. So that's a simple way that we can automatically detect a gulp file, run the tasks, or even change how that tasks are working using arguments.
-
Automatic Grunt Detection
Let's take this from a different angle. We just saw how we can use gulp and read those tasks in or we saw how we can use babel or typescript and use those directly from vs code. Let's take a look at another option, because we can also auto detect from Visual Studio code and a grunt file or a jake file. So we'll use a grunt file. In this case let's go to just an empty folder and create a new project. So first we're going to make a directory and I'll call this my grunt project. And inside of there I'm going to go in and then I'm going to open up code just like that. So now we've got this grunt project. Now inside of here we're going to create a couple JavaScript files. Let's create one first where we saw we got a variable called first and we're going to set that to John. And then I'm going to save that file. And we're going to call this one, I don't know, app js. So we're good. Now let's create a grunt file. So we'll hit Command + N to open up a new file or we could always just right-click and choose new file. And here's where we're going to put our grunt code. So first we're going to put it a todo in here to say, add grunt code. Now we're going to save this file and it's important with grunt, just like with gulp, to name things appropriately. It's got to be called gruntfile.js. The conventions a capital G, but hey I like to buck those sometimes. Now let's go back out to terminal, we need to make sure we've got our grunt package installed. So first you want to make sure you run npm install, grunt cli, -g that's going to put the cli install globally on the machine. And that's going to allow us to run our grunt commands anywhere on our computer. Once we have that, the next step is to install grunt itself locally and then something to run with grunt. So first, let's go ahead and make sure we've got a package JSON file. We're going to run npm init in this project and I'm just going to keep hitting enter. And let it take all the defaults. And over here on the left we're going to see in vs code a package JSON. Perfect. Once we have that, I'm just going back over to the top, make it easier to read. I'm going to say npm install and now we're going to install grunt, this is the local version of grunt. And we're going to install a package called grunt contrib js hint. And we're going to make sure these are both saved inside the package JSON, like this. So why do we install these guys? Well we're going to need to run grunt locally. And we're going to want to run something with grunt, maybe to js hint our code, so we can make sure we don't have any problems. Cool. Now that we have all that we can test this out quickly, we have not tasks, but we can run grunt at the command line. And you can see it's saying, hey I don't have a default task, that's because we haven't done anything with grunt yet, but at least grunt's there. So now let's go back to our grunt file and let's add in our grunt code. And when you setup grunt you get to have an initial configuration and there's a command called init config. And we passed it that, our configuration, we're going to have this task called js hint. And we're going to tell it to look at certain files. And the first files going to be our grunt file. So we're going to js hint our file itself, the one we're in. And then also any of our code. In this case we're just going to say, okay anything at the root that ends with *js. So that's our configuration, now we have to load the tasks that we had, that contrib js hint, so to do that we use this load npm tasks. And then finally we'll register our task name that we can run. And you can name it anything you like, I'm going to call mine grunt hint. And when it runs it's going to run my task up above called js hint. Now before we run this, it's always a good idea not to run it against every file basically there. So let's go ahead and just create a new folder called source and we'll stick our app js inside of that source folder. So by dragging it and we'll come back up to here and now we'll say, okay run for everything under source and then find the js files. So now just to test this out, let's go over to command line and let's run grunt, grunt hint, and when we do that it says we have two files lint free. Let's go ahead and make a mistake over on the app js file, let's just get rid of the semicolon first. And when we come back over here and we can see now we have an issue. So we know that that's working. Alright that's great, but how do we run this from inside of our tool? So coming back to Visual Studio code without using terminal. Now I can run back up to the pallet I can type in task (space) and notice it found two tasks. It saw we had a grunt file and it noticed that we had a task inside of it was defining the config called js hint. And the register task that we created called grunt hint. And I can run that and we'll see the output on the right-hand side. So if I come back over here inside of the grunt file, we'll see that right there. There was the first task, the js hint, and the second task is there on line 11. So vs code has some built in intelligence to look for some of the most popular task runners out there, like jake, grunt, and gulp.
-
Debugging Gulp and a Gulp Task
Let's say that you wanted to take a gulp task that you had and you wanted to debug it. Well if we combine what we learned in this module and the last module we can achieve that. So let's open up the code play project and we'll create a new launch configuration to help us debug our gulp task. So I'll put it right there and notice it's green, by the way, that means there's a warning because I'm missing the name and type properties. We're going to enter those in the require. So let's type in the name here and let's call this a node gulp debugger. That'll be the name that appears when we try to run it. And the type is going to be node. Alright so how do we actually run this process? If you notice down on line 17, we were running the app js file. Now we need to run the gulp file. And not the gulp file that we created, but actually gulp itself. So instead of app js, let's go ahead and find that gulp file. Now notice I typed in node modules, gulp bin, gulp js, so let's go take a look and see if that's where it is. Here we've got the node modules and down here we've got gulp bin and gulp js. Inside of there this is basically the brains of gulp. So that's the thing we're going to kick off. Next let's hit the stop on entry and let's also set the runtime args and we'll set this to no lazy. Well now we've got something to kick off the debugger running gulp. And by default this is going to run the default task. Now let's go and look at our gulp file.js. And notice here we've got a default task, which is set to the help task. Well I actually want to debug the vet task down here, which is running js hint and js cs. So I'm going to set that default task to run vet. That means when I run my debugger, it's going to kick off gulp with no arguments and then it's going to automatically run gulp vet. Now just so we can make sure we know what's going on here, let's go ahead and first set this back to true. So I'll stop on entry. Now let's go inside our gulp file again and we'll set some breakpoints. One of them we'll put right here when it processes the task and another one when it actually runs the task. Now setting breakpoints in our code is good, but we can also set breakpoints inside of the gulp file. So we can come up through here and we can set a breakpoint, maybe I don't know down here on line 37. And now let's go back to our launch JSON and let's run this. So to run it I'm going to click on the debug, we'll make sure that we're running node gulp debugger. We'll click on the run and immediately it stopped on the entry, because we set that to true. So it's right here at the use strict and we can start looking at properties, none of which are being used yet. Let's hit the run again it'll run to the cursor, to where we put the breakpoint right there, in cli package. Now that hasn't been set yet, but these other guys have been set. Notice these functions now exist and the cli object exists. Alright so now we can hit run again and the next thing is does it processes our gulp file where it sees, okay that's the task called vet. So it's registering all these tasks. Now we can hit run again and it's actually running the vet task now because we told it to do that, that's the default task. So we can see now it's going to log this and we can jump over it once. And we can now inspect things like okay we know there's an object here called config so let's go up into the closure. And we can take a look at config and we can look at all js and see what's in there. So if you're wondering what these values actually are, it's a great way to debug gulp. And notice we set a breakpoint inside of gulp itself, our custom gulp file, and it can even set breakpoints inside of the gulp plugins by just putting breakpoints in the files inside the node modules folder. For example, let's go inside of gulp js hint. So we come back over here, we can look for that up inside the node modules folder. Here's gulp js hint and inside of there we've got it looking at node modules and then js hint itself. You can keep diving in, there's multiple levels in there, if we'd like. And then here's the js hint file and we can set a breakpoint in there, maybe looking for parsing as a semicolon. So let's say we want to make sure whenever we're breaking this particular rule, w033, which is a missing semicolon, we stop there. So for now let's just let it run through. And it's not hitting it. But let's say we break this out and now let's go into our dashboard controller and let's remove a semicolon up there. Now let's run the same process, F5 here, that'll run the last command I selected. We'll hit the green arrow again or we can hit F5 to run to the cursor. I'm going to walk through our breakpoints. Now we're logging it and now we're running the actual vet task and notice now it did hit this breakpoint indeed, because I'm inside of here at this warning for 033. What does that mean? It means I missed my semicolon. So if I open up the panel on the other side we go back to our dashboard file, we can see that this is the line right here, line 6, is the one's that missing it. So if we close that out we can start looking at state tokens current line. Here's the closure, there's the state, and we can look for tokens up here. And there's current and then we can look for the line number and that should match, see line 6. So this is a nice way that we can combine different things that we've learned here by seeing how we can debug tasks.
-
Debugging Tasks via Arguments
Right now we've got relying on being the default task for gulp. Well that's not too flexible, so let's make sure that we don't do that. We'll put it back to help the way it was, but if I want to debug a task, like vet or any other task, probably a better way to go. Let's go inside launch JSON and then up in here we can pass in arguments. And that argument could be what's the name of that task? Well let's go back and now let's do vet, so it's actually going to run the gulp program and then it's going to run vet right after it, which is then going to jump into that particular task. So now if I press F5 again, it should crank things up, stop on entry. We'll hit F5 again it runs down to my breakpoint, I do it one more time now it's processing the task and now, and the next one should be the one where it actually tries to run gulp vet. And there we go. So now it's running through the logger and we probably still have our problem with the semicolon, so when I run through this we're picking up the warning. So we can see again that we can walk through here we can inspect values, check the call stack, hit breakpoints, do all sorts of things while we're using the launch JSON to debug our tasks.
-
Recap
We've seen just how much you can do with tasks inside of Visual Studio code. And it's not just another task runner, it's a way to leverage existing task runners right inside the tool. For example, we can run Typescript or babel or gulp or grunt or jake, pretty much anything you can run from the command line, you can do right from a task inside of vs code. That also means that anything that comes down the road, we can also run from there. And along the way you saw me type a few commands over and over again, so let's just go through those really popular commands like running a task or terminating a task. It's important to be able to do those right from the command pallet. And of course to configure a task runner, which brings you right to the task.json file. All of those you can open up from the command pallet using this keystroke. I like to assign keystrokes of my own for run and terminate tasks. And then you need to see the output of the task too, so you can toggle that output by using Command + Shift + U. And that'll open it or close it. And there's really a couple flavors of tasks that we can run. Here's an example of one of the simpler ones where we basically just want to shell out to run the typescript compiler. So we tell it the command is tsc, this is a shell command and we give it some arguments, like go run the code in this folder and make it a watch. That way it'll keep recompiling the typescript when it sees any file changes. And it also uses a problem matcher so we can get any errors that we find and bring those back into the tool. Which is kind of cool, that way you don't have to watch the terminal for your issues, you can actually have vs code find all the issues for you. And that's a relatively straightforward task, but what if you wanted to do something a little bit more custom? Here's an example of inside the task JSON how we set up a couple different tasks. This one here is going to have the command of gulp, right on line 3 and then notice a task name we created on line 18. We're going to run a task called serve-dev-debug. Now that's actually going to run gulp and then run a task called serve dev and then use the ---debug.brk as flags. So what we're doing here is saying, okay go ahead and run gulp, I know there's some kind of task inside of the gulp file called serve dev, right here on line 20. But I want to run it with this special flag. So this is a way we can override that and say don't just run it by default, run it with this particular flag. And then line 23 says, suppress the task name, which is the thing on line 18. So we can basically take any gulp file and we can tweak things a little bit by overriding it with flags if you want to. And then grabbing any problems it finds, like the js hint stylish problem matcher. So we can pull those js hint issues right into the tool to report them to us. Well the task JSON's really powerful and we got all our task output right side by side with it. But don't forget about that little spinning wheel in the bottom left-hand corner, that's our task indicator. Why? Because if you're running a watch or anything that's continually running, that thing will be spinning around in circles for you. So that's how you know it's there and you can always go terminate that task later. So you want to keep an eye on that running task and watch that indicator, that's why I like to have a special keystroke, I use Command + Shift + X to terminate that task. That's what's great about the custom key bindings. So we learned how to leverage different kinds of task inside of vs code and connect those using the task JSON, which is the configuration for the tasks. And through that task JSON we're able to connect the things like babel or typescript and run them right from vs code. And then using problem matchers we could pull in any issues from those tools to report them in the errors and warnings window in vs code. And if you want to use one of the more robust task running systems out there, like jake or grunt or gulp, it'll automatically detect those kind of files inside of vs code and read those tasks in. And then we wrapped up by showing how you can debug all your task code right inside of vs code. And the ability to run other tasks or to use existing task runners, is one of the places vs code really shines in its flexibility.