Hey, I'm Andrew Connell. This video is one of the chapters from the free starter bundle of my Mastering the SharePoint Framework course by Voytanus. You can find the other free videos from the starter bundle that are listed in the description below. Now that course contains over 35 hours of in-depth explanation and instructor-led demos all by me that teaches you everything you need to know about the SharePoint Framework or SPFX and to become a master at it. I offer the course in three different bundles. The starter bundle, that's everything I've already mentioned, as well as two other bundles, the fundamentals bundle and the ultimates bundle. Each bundle contains more content than the previous bundle and some additional resources. You can learn more about the course on my site that's linked here as well as linked in the notes in the description below. Now with the context set, enjoy the rest of this chapter. Hi, welcome back to the course. I'm Andrew and this is the third chapter of my course on mastering the SharePoint Framework. Now this chapter is gonna explain and walk you through the process of getting your environment set up and fully configured so that you can start working and developing with the SharePoint Framework. So what exactly can you expect from this chapter? We'll first start out with a look at what you're building with the SharePoint Framework and how it differs from what you've built when creating SharePoint solutions or add-ins, be those Farm or Sandbox solutions, SharePoint hosted add-ins or provider hosted add-ins. And this is gonna help you keep in the back of your mind what you're building and how it will run when you're setting up your environment because it'll answer some questions as why some of the new tools are required and why others that you used to use are no longer needed. Then we're gonna look at the SharePoint Development tool chain that SPFX leverages. You'll quickly see how different the world is when building customizations based on the SharePoint Framework. So if you're a traditional SharePoint developer, this can be quite a shock to what you're used to. For those of you who have experienced as SharePoint developers, I will draw on the parallels to the tools that we used to use when building solutions or add-ins because nothing from a high level has really all that much changed. Only the tools have changed. But if you're one of those developers who's got experience with this modern web development tool chain and these popular open source tools, this stuff may be a whole hat to you. So you may wanna skip over that lesson. One thing I notice with traditional SharePoint developers venturing into the world of SharePoint Framework development is that they get overwhelmed very quickly. And I believe this is because there are a lot of unfamiliar tools and technologies that are introduced that you have to install and get through just to build a simple hello world client side component. But you know what? You don't need to know all these things. Some of the things you can just install and completely forget about them and just ignore them in the future. So I'm gonna show you what you need to know and what you can ignore and just be aware of the fact that it's there and that you're using it but you don't have to know anything specific about it. Now developing for the SharePoint Framework, it's gonna require that you have two different things. First, you need a place to deploy and test your customizations. Just like traditional SharePoint development, you'll use SharePoint for this. Now we're gonna start by getting you set up with a SharePoint developer tenant in Microsoft 365 or using an existing tenant. While SharePoint Framework is supported in some on-premises SharePoint deployments, this course focuses just on SharePoint online. So when I discuss a topic that applies to just SharePoint online, I'll make a point of mentioning that but assume what you see works on-premises as well. So if you're an on-premises customer, don't think that this course is just for those people who are on SharePoint online but as I talked about in previous chapters, there is only limited support for the SharePoint Framework on specific on-prem deployments. So there are only certain things you're gonna be able to do and certain things you can't do. I'm covering everything in this course and you'll just have to figure out like what is available just on-prem and you can do that based on the versions that are supported both on-prem and what versions are, what's in that version, what features and what versions they were introduced in the SharePoint Framework.  You're gonna find a series of lessons on this topic in this chapter on getting your developer environment set up as there are a few frameworks and tools that you need to install and configure. You'll find a lesson on each one of these different things. Sound good? Fantastic, then let's get started and let's jump into the first lesson. Hello and welcome back. In this lesson, I wanna take a moment and I wanna talk to you about command prompts. Working with command prompts, it's a common thing in modern web development and before we start using them, I wanted to talk a little bit more about them before we started diving into the course. Now one aspect of SharePoint Framework's developer tool chain is that it supports cross-platform development and this means that you can use Windows, Mac OS or Linux. Now my platform of preference, it's Mac OS. So that's what you're gonna see throughout the course but just know that there's nothing I'm gonna demonstrate is unique to Mac OS. If you prefer Windows, your experience is gonna match mine. Now, if by chance there's a case where something I'm doing is Mac OS specific like a special command line statement, I'll be sure to share the Windows equivalent with you. The biggest difference that you see in the different operating systems is the command prompts. Command prompts can be very different between Windows and Mac OS and the default ones on both platforms, they leave a lot to be desired but both platforms offer multiple alternatives. Now let's start about talking about the Windows command prompts. Nothing about these makes your SharePoint development experience better or worse. It's entirely a personal preference. The default command prompt on Windows is the cmd.exe. It's been around for years, decades, but it's boring, it's dated and there's so many better options. SharePoint framework developers are also free to use the PowerShell command prompt if you like. Now, another option is the Windows subsystem for Linux and it lets developers run a Linux environment including the most command line tools, utilities and applications directly on Windows, unmodified without their overhead of a traditional virtual machine or dual boot setup. And this is referred to as WSL2 as we're on the second iteration from this. You can learn more about WSL2 from the Microsoft documentation and you'll be able to leverage this doing SharePoint development as well if you prefer. Commander is a software package that was created out of pure frustration over the absence of a nice console emulator on Windows. Commander for Windows is a terminal emulator that adds a ton of improvements to the default command prompt in Windows. It really came about before the Windows subsystem for Linux came out and it was really my preference or my recommendation to people what they should be using. But now with WSL2 being something that's almost out of the box in Windows, maybe that's what you want. I don't know, it's really up to you. If you're on Windows, you've got four different options that I would consider. Really, I'd probably narrow it down to either Commander or WSL2. Now Mac OS has a couple options as well. Let's look at the different command line prompts options that we have available on Mac OS. So terminal is the default command prompt in Mac OS and just like cmd.exe on Windows, it's real basic with no frills and frankly, it's really boring. Another option is Iterm. Iterm for Mac OS is a super powerful emulator that also adds a ton of improvements to the default terminal on Mac OS. So this is another one that you can use and this was my favorite for a very long time. But in addition to the command prompts for specific platforms, there's cross-platform options that have evolved over time. One that I'm real happy with is one called Hyper. Hyper is a command prompt that's built using TypeScript and it works cross-platform. So this one has become really popular with its plugin model and adding support for user-contributed features and themes. You may want to take a look at this because it works the same way both on Windows and Mac OS. Now, when I originally recorded this course, I was using Iterm on Mac OS with the OMI-ZSH shell extension. OMI-ZSH is a community-driven framework for managing your ZSH shell when you're on a UNIX-based system. ZSH, it's based on Bash, the shell that is really popular on UNIX systems. That includes Mac OS and Linux. So you can take a look at the lesson notes to learn more about these different tools. I'm not going to dwell on them here as they aren't important to the SharePoint framework development. I'm only mentioning them because some of my students ask a lot about them. So on my environment, I'm on Mac OS, I'm using the ZSH shell instead of using Bash. I'm using OMI-ZSH to configure that and customize that and then I'm using Hyper or Iterm to as my emulator or think of that as my RDP into my console kind of a thing. You can think about it more like that. My Iterm experience was also really customized. So more recently, while I still use OMI-ZSH and ZSH for my shell, I've been using Hyper instead of Iterm because it's really more of a simple setup and config. Throughout this course, you're probably going to see a mix of command prompts between Iterm and Hyper, but what I use, it doesn't really matter. You pick the command prompt that works best for you and your environment. Okay, so that wraps up my discussion on command prompts. Now, let's start getting at your environments ready for SharePoint framework development. So I'm going to see you in the next lesson. So then welcome back. So before rushing into configuring your developer environment, just take a minute with me and I want you to consider what you'll build and deploy as part of your SharePoint framework customizations. If the SharePoint framework is your first experience with SharePoint development, then you might want to skip this lesson because this lesson is primarily for those with SharePoint experience and trying to wrap their brains around this SharePoint framework development model. If you're a traditional SharePoint developer, take a minute and consider with me what you use to build. As traditional SharePoint developers, you had the option to build a few different things. Farm Solutions involved building some sort of a solution package, which was Microsoft's cabinet file with a WSP file name extension. Now, this file, it always contained things like declarative XML files with features and element manifest files. And most of the time these farm solutions, they also included things like web assets, things like HTML, ASPX pages, JavaScript files, CSS files, images, et cetera. Could be a bunch of other stuff as well. Usually, you also had compiled.net assemblies, DLL files, that implemented features or event receivers, web parts, timer jobs, could be a bunch of those different things. Now, Sandbox solutions were no different than a farm solution as far as these were concerned, but as I said earlier in a previous chapter, these more recently, they can't contain compiled assemblies, but other than that, they're basically the exact same thing. Now, to build these things almost all the time, you always use tools like Visual Studio with the Office and the SharePoint tool extensions that were installed for Visual Studio. And these were the only tools that knew how to create these solution package files that would be used in our deployments. And you did this development typically on a local SharePoint farm or really just a virtual machine that had SharePoint installed on it. That was a fairly powerful developer workstation that had to run a SharePoint and Windows Server and SQL and all that other stuff. After solutions came SharePoint add-ins. One type of an add-in was the SharePoint hosted add-in. And under the covers, these were very much like Sandbox solutions as that's the provisioning vehicle that we used to use to get things into the targeted site. These things included things like a solution package that also included things like the declarative files that I've talked about earlier and the solutions. These were for the element manifest files and the features and et cetera. We also had things like web assets. And then all of this stuff was packaged up in a special zip file that made the SharePoint add-in package. These were no longer, the provider hosted add-ins were no different as the registration part of the add-in could include the same stuff, but minimally it had an XML file in the package add-in or in the SharePoint add-in package to register the add-in with SharePoint. The part of the provider hosted add-in that was used to implement the remote web application was dependent on the technology that was selected, but that wasn't deployed by SharePoint. That was deployed by you, the provider or the developer. Now to build these things, you always used Visual Studio. This always had the Office and the SharePoint tool extensions for Visual Studio installed. And just like solutions, these are the only tools that knew how to create an add-in package file that could be used in our SharePoint package deployment. Now while you could use or leverage a local copy of SharePoint to test these solutions, Microsoft did make the story a little bit better where you could leverage either in on-premises environment or a hosted environment in SharePoint Online and Microsoft 365 to debug and to test your add-ins. Now how does this style of development compare to the SharePoint framework style? Now the things that you'll build for the SharePoint framework to deploy into your SharePoint deployments, these things, you're just gonna be deploying assets. What you build will be used to implement a client side experience. But like solutions, add-ins, you need an add-ins, you need to have a way to get these into your SharePoint environment. And this can be done using SharePoint packages. A SharePoint package is just a special zip file. This package contains all the files needed for your customization, as well as a few generated JSON and XML files that SharePoint needs. Now you need tools to create those packages. And this time around, Microsoft is providing tools that leverage popular cross-platform open source tools. The implications are that you no longer need Visual Studio or a full-blown copy of SharePoint to test things out locally. And as you'll see in this chapter, this yields a lot of flexibility and choice, which is great as it opens up SharePoint development to many more developers. Now if I had to tell you what the complete developer environment would look like, I'd probably say using a text editor like VS Code or Visual Studio Code, the one with the blue logo, and a SharePoint site collection within Microsoft 365 tenant. Now to put my cards on the table, we don't have tools like Visual Studio. That might be frustrating to those of you who are only familiar with using Visual Studio as your SharePoint developer environment from the previous days. Now with a look back at what we used to do and how it's different to this new world of SharePoint framework development. In the next lesson, I'll explain the development tool chain that Microsoft has selected for SharePoint framework development before we start setting up our environment. So I'll see you in the next lesson. Hello and welcome back. Now one thing I noticed with traditional SharePoint developers venturing into this world of SharePoint framework development is that they often get overwhelmed very quickly. Now I think that's because there are a lot of unfamiliar tools and technologies that are introduced, that you've got to install and get through just to build a simple hello world component. Now this lesson is gonna serve two different purposes. First, I wanna provide an overview on what the development tool chain looks like for SharePoint framework development. You'll learn everything that's involved, that's role and how it compares to the traditional Visual Studio and SharePoint server side development world. But my second goal is I want to highlight what you need to know. As I'll show you, there are a lot of tools and there are a lot of pieces that are involved. Some of these things, you'll need to know and understand well and others you can just accept as, okay, I need that, check. And then move on.  You just aren't gonna have to deal with them going forward. Okay, there are two parts to being a developer in terms of what you need to get your job done. One is the environment and the other is the tool chain. From the SharePoint environment, there are two scenarios you wanna address. The first is the local developer environment. Now, Microsoft really improved this story for SharePoint developers with the SharePoint framework. We now have something called the SharePoint workbench. Now, this is a hosted page that you can host your SharePoint client-side web parts and using this page, you can develop and test your web parts all without a full SharePoint deployment on your laptop. Now, cards on the table, for the first few years after SharePoint framework was released, you could build and test your client-side web parts locally without a SharePoint installation using something called the local workbench. However, that's changed in the latest versions of the SharePoint framework starting in 1.13. That mean what they did there is that's the first version that dropped the local workbench. That's okay because every SharePoint site in SharePoint environments that support the SharePoint framework contain a hosted version of this workbench. Now, the other aspect to a development environment is a SharePoint developer tenant. Now, this is a tenant in SharePoint Online in Microsoft 365. You'll absolutely wanna test your customizations here as it's a real SharePoint environment. And this environment also has a copy of the SharePoint workbench that you can use to test your web parts out as well. Now, this means you need a real SharePoint environment to truly test and debug your custom solutions. And throughout this course, I'm gonna use the hosted workbench. But some of my older lessons that may demonstrate me using that old local workbench because it was still available to us. Just keep in mind that everything we do in the local workbench is available in the hosted workbench. You'll see the workbench once we start building SharePoint framework components starting in the next chapter in the course. Now, the other aspect to development is the tool chain. Now, I like the definition from Wikipedia. It says that a tool chain is a set of programming tools that is used to perform a complex software development task or to create a software product. Okay, Microsoft elected to adopt the popular open source based modern web development tool chain for the SharePoint framework. And this includes using things such as Node.js and NPM. Node.js is the runtime and NPM is our package manager. We're also using Yeoman to create the project scaffolding. We're using Gulp as a task runner. And then we're also using a tool called Webpack. Webpack is gonna handle the bundling of all of our assets together. For those who aren't familiar with these tools, let's look at them when compared with the traditional Microsoft development tool chain. Now, I'm not gonna spend a lot of time on these tools at this time. Rather, I want to draw some parallels for you. This chapter's got a lesson on each of these tools where you can learn more. Now, the traditional Microsoft way of doing development is to build on the .NET framework. And this is the runtime that knows how to run all of the different programs. Node.js addresses this need. A lot of the tools in modern web development world are built on top of Node.js. So as you can see where we're going with this picture is the top row is what we've used to do with traditional SharePoint development. So if we did add-ins or sandbox or farm solutions, the bottom row under the timeline that you see there where it starts with Node.js, that's what we're gonna be doing with the SharePoint framework. Now that we have our runtime defined, let's talk about the next piece. When building a .NET application, we use a tool called NuGet to acquire prebuilt packages for use within our application. But in the Node world, we use a tool called NPM that does the exact same thing. We will use this to get our package customizations that we need, like jQuery reusable components or other useful libraries that we wanna use in our projects. Now Visual Studio is Microsoft's integrated developer environment, an IDE. And when we wanna create a new project, we use Visual Studio's project templates to create the file and folder scaffolding for the project. But at the SharePoint framework, you can use any editor that you want. But to get the file and folder structure created for the project, we use a tool called Yeoman. You can install different project generators for Yeoman and Microsoft even provided one for the SharePoint client-side web parts that we use as our starting point for our new project. Now, this next comparison is more about languages. And in my experience, I see most SharePoint developers building compiled assets. Sure, they're web assets like HTML, JavaScript and other CSS files, but most of the time people are using C-sharp. Okay, but the SharePoint framework, it's exclusively client-side and thus it must be JavaScript. However, Microsoft has elected to strongly encourage the use of TypeScript as the language of choice that will be transpiled down to JavaScript. Now, you know when you build a project in Visual Studio, some processes kick off to compile the project and maybe it manually starts up another process with your app in it and attaches to a debugger. Visual Studio is not doing that. That's Visual Studio calling a tool called MSBuild. Someone created a task for MSBuild using XML that tells it what to do, such as compile the project, copy the files from here to there and fire up a process followed by attaching the debugger. In the SharePoint framework, we use a tool called Gulp. It does the exact same thing and it allows us to write tasks using JavaScript and then tell Gulp to run those tasks for us. Now, this last comparison is not really exact, but you're gonna get the picture. With a traditional SharePoint project, you compile the project files into an executable or a DLL, but in the JavaScript world, we have a similar process where we wanna merge all of our multiple files into a single, bigger file for performance and manageability and the tool that Microsoft selected to do that for us and with the SharePoint framework is Webpack. It's a lot of new terms, isn't it? Okay, but don't worry, don't sweat it. You don't need to know and become an expert on all of these things or be well-versed in all of these things. And while you might need them, some of them you can just ignore after you've installed them and just know that they're being used. In my opinion, you really only need to be versed on how to use a couple different things. Get familiar with a couple different tools, NPM and TypeScript. You need to get familiar with TypeScript as that's the language that you're gonna be writing all of your stuff, all your code with. And as for NPM, you need to get familiar with it as it's the tool that you're gonna use when you wanna update your tool chain as well as find, install, and update external libraries that you're gonna use in your projects. But forget about things like Node and Yeoman and Gulp and Webpack. Sure, you can learn a lot about them but you can get by just fine with just installing them and letting the tools that Microsoft provides to run and configure them for you. At least that's the approach that I'm gonna take. There are a few commands that you need to learn on how to run tasks with Gulp or kick off a Yeoman Generator but I wouldn't consider that really learning these tools. So in this lesson, what you got was an overview of the developer environment and the tool chain that you're gonna use for developing with the SharePoint framework. The rest of this chapter's lessons will be filled with demos showing you how to configure your environment for developing with the SharePoint framework. So let's get going. Hello and welcome back. Okay, up until now, you've just listened to me explain what the SharePoint framework is all about and tell you what the developer environment looks like. Now it's time to get to work. Let's get your environment set up so that we can start building and testing stuff. The first thing that you should do is set up a SharePoint online tenant to use for development. For the first few years after SharePoint framework was released, you could build and test your client-side solution web parts locally without a SharePoint installation using something called the local workbench. However, that's changed in the SharePoint framework, version 1.13, which dropped the local workbench from the SharePoint framework. And this means you need a real SharePoint environment to truly test and debug your custom solutions. So in this course, I'm gonna use a developer site and SharePoint online in Microsoft 365. There are a few different ways to get this site. You can use your company's existing Microsoft 365 tenant, a Microsoft 365 tenant from an MSDN subscription, maybe a tenant that you got as part of being a Microsoft partner or even you can get a developer tenant from Microsoft. Whatever you already have, I recommend that every SharePoint framework developer sign up and get their own tenant for free. You can do this by joining the Microsoft 365 developer program. It's entirely free and it gives you everything that you need to get started. I'm using mine to test all the solutions in this course and I'm gonna assume that you've already signed up for the developer program and everything has been provisioned. This can take anywhere from a few minutes to a few hours. So first up, let's get your SharePoint online developer tenant created in Microsoft 365 so we have a real environment that we can test against and in addition to a local environment. This involves two steps. The first is to create an app catalog where you can upload generated packages that contain client-side web parts and the second step is to create a developer site where we can test these client-side web parts. All right, so let's go ahead and get our environment set up. So the first thing I'm gonna do is I'm gonna head over to the Microsoft 365 portal.  Now, before I do that, I just wanna highlight one thing. So if I go to docs.microsoft.microsoft.com slash SharePoint slash dev, that's gonna take me to my SharePoint developer documentation. If I go to the SharePoint framework section and under getting started, there's a setup my Microsoft 365 tenant. What this is gonna do, I'm gonna basically follow the instructions on this page right now. But one of the things it refers to, it gives me a link to the developer program. Because it takes a few minutes for you to sign up for the developer program and to get all of the resources initialized, if you do it right now, you're gonna have to come back in about 10 or 15 minutes because it takes time for SharePoint to get provisioned as well as other resources inside of your SharePoint, your Microsoft 365 developer tenant. And so to save some time, I've already gone ahead and signed up for a developer tenant and then did the initial stuff. There's documentation on the developer program site that walks you through what you need to do to get started. Once that's done, we need to go in and get our SharePoint environment setup for doing SharePoint framework development. That's not in those instructions. That's in the instructions you see here on the developer docs site. So what I'm gonna do is come back over here to my portal. So I know that my name is, my sign in is Andrew Connell at Voitanos dev2onmicrosoft.com. And let me go grab my password and I'll go ahead and say signed in. And this is gonna launch the Microsoft 365 portal. Now, depending on when you watch this video, they may have added some stuff, they may have moved some things around. It's not uncommon for them to do that.  You can always refer to the SharePoint developer documentation for like a step by step on how to go through and to get this set up. All right, so once the portal loads, I'm gonna come over here to show all down at the bottom for our admin centers. And I'm gonna see an admin center for SharePoint. If you don't see that, just need to be patient.  So I'm gonna come over here to more features and I'm gonna scroll down to where I find apps. There it is. And I'm gonna select open and then I need to pick an app catalog. So I'll select app catalog. And I don't have one created, so I'm gonna say go ahead and automatically create it. So I'll say, okay. All right, so now we have our app catalog set up. So we can see it's at sites slash app catalog. We're gonna use that a lot in the course. So I need to remember that.  So I'm gonna go to my list of sites. I'll go to active sites. And I can see I have one site listed, but let's go create a new one. So I'll select create. I'm gonna pick a team site. I'm gonna give this one, I'll call this my primary dev site. Group owner is myself. So I'll just pick that. And we can see the URL where it's gonna be primary dev site. So I'll just say next.  So we'll give it a second. We can see that it's finished. There we go, primary dev site. I'll select that to open up the site. And ta-da, we have our primary dev site. So now we've got our app catalog set up and we have a site where I can go test things for my SharePoint development. Specifically, let's come over here and let's make sure that the workbench is there. So I go to slash underscore layouts slash workbench.aspx and fantastic. That's what we wanna see. The warning obviously we don't wanna see, but that's okay. I'll explain why we're seeing that when we get to doing more of our development a little bit later. But for right now, there we go. We're in good shape and our tenants all set up and ready to play with. Okay, that wraps up my discussion and my demo on setting up your SharePoint environment. So in that demo, you saw how to create an app catalog and your developer site collection in your SharePoint online tenant, which you're gonna use to test your SharePoint framework components throughout this course. So with that done, now we can start on setting up your developer environment on your laptop. So I'm gonna see you in the next lesson where we're gonna kick that off. Hello and welcome back. All right, now that we've got our SharePoint online developer tenant provision, let's switch our focus to our local developer environment, our laptops. All the tools that we will use in the development tool chain are built on top of Node.js. So that's the first thing that we need to get set up. Now in this lesson, we're going to look at Node.js and NPM. And once we've done that, I'm gonna demonstrate how you can install Node.js on your developer environment, regardless if you're using macOS or if you're using Windows. So let's start with the question, what is Node? Node is a cross-platform runtime that enables developers to create applications written in JavaScript that run on devices such as servers or desktops or laptops or embedded devices, a lot of different things. It does this by hosting the Chromium Projects V8 JavaScript engine. Chromium is the open-source browser project that Google's Chrome browser and Microsoft's latest Edge browser are both based on. It also includes APIs for interacting with the local device for things like IO, environment variables and networking. Now there are two main distributions of Node.js. The long-term support version or LTS is a version that has strict requirements for new features and updates. This is the version that many enterprises use because it's not always changing and improving. It's also the release track that Microsoft recommends for development with the SharePoint framework. Now furthermore, each SharePoint framework version is only gonna support specific Node versions. But refer to the notes for this lesson under the video for a complete list of SharePoint framework versions and the versions of Node LTS that each supports. You should pay attention to that based on when you're installing your environment and make sure you get the correct version. Now, the other is what they call the current version of Node and this has the latest features that are added to Node.js. Eventually these features, they're gonna make it into the LTS version but in the current release path, they're much less mature and they're much more frequent in terms of what gets added. Now, why do you even need Node? Well, because most of the tools that we'll use in the SharePoint development tool chain, they're all built on Node and they require it and this gives us the cross-platform aspect of SharePoint development. Okay, now with that brief overview of Node behind us, let's talk about something called NPM, the package manager. Let's start with a question, what is NPM? NPM is Node.js' package manager. It's a Node.js based tool that you're gonna use to acquire and manage your packages within your projects. Some Node.js tools are also distributed using NPM. So for instance, when you want to install a new version of TypeScript, the TypeScript compiler, you're gonna run a tool, you're gonna run in a command like NPM install TypeScript and this tells NPM to install the package TypeScript globally. Now, when you install something globally it's available anywhere on your laptop. If you leave off this dash G, which is the global flag, when you install it, it's only installed locally, so it's only available in the current working directory. Now there are two ways that you can get Node.js installed on your environment. The first option is to head to the Node.js website, download an installer for the latest LTS version for your platform and follow the instructions. Now, this option works, but you'll find at times you have to work with Node.js as an admin, either within an administrative command prompt in Windows or by prefixing any Node-based commands with the command sudo on macOS or Linux. The other limitation of this approach is that you can only have one version of Node.js and NPM installed at any time on your developer environment. Generally it's not that big of a deal, it just can be annoying. Now the other option that I prefer to use is to use something called Node version manager or NVM. Now, I'm not gonna go into a ton of depth on NVM or why I love it here in the course, but I have published a blog post around it that you can check out. Refer to the link that I've shown that I've included in the lesson notes here for that. Once you've installed NVM, it's gonna allow you to, it's gonna help you actually to do a couple of different things. It's gonna help you acquire different versions of Node and switch between them very easily. Each Node.js install that you get has its own global package installation folder so that you can have different packages globally installed with different versions between different Node runtime installs. So let's consider like a use case for this. Let's say that you're a consultant and let's say you support customers who work on both SharePoint online and SharePoint on-prem. Let's just say it's SharePoint Server 2019. Well, SharePoint Online supports the latest version of the SharePoint framework. So if we look at the state of the SharePoint framework in 2021, that means that we're using Node.js LTS version 14. We're using Gulp V4, Yeoman V3, and the Yeoman Generator for the SharePoint framework of 1.12.1. The big things I want you to pay attention to are a couple of different version numbers though, okay? But when you need the context switch and do work for your SharePoint Server 2019 customer, your development environment's gonna be a little bit different. You can only use Node.js LTS V8, Gulp V3 instead of V4, and then you can use any of the Yeoman Generators for the SharePoint framework from versions 1.4.1 to 1.10. The reason you can use any version of the Generator 1.4.1 up through 1.10 is because of the version of Node SPFX's build tool chain, the version of Node that SPFX's build tool chain supports. SharePoint Server 2019 only has support for the SharePoint framework 1.4.1, and the latest version of Node that that supports is LTS V8. However, the SharePoint framework Generator V1.10 can create SharePoint framework projects as low as 1.4.1. But the 1.10 version of the Generator is the last version that supports Node LTS V8. I'll explain this a little bit more later in the lesson when we get to Yeoman in the chapter, but let me get back to NVM. If you use NVM to manage your Node installs, you can easily switch between two different Node environments, each configured with its own globally installed packages. If you installed Node without NVM to support both of your customers, you'd have to uninstall all the tools and then go back and reinstall the desired versions and then repeat that process to go back to the other customer. That's a pain, but with NVM, I can have one environment set up for SharePoint online development and one environment set up for SharePoint 2019 development. And then I can just use NVM to say use that one or use that one instead of uninstalling and reinstalling and then uninstalling and reinstalling if I chose option one that I showed there on the slot. Now you might see why I like NVM. In my mind, it just makes a heck of a lot more sense. But there's also some other big benefits to it. It's gonna help you avoid command prompts or admin command prompts because Node is installed within your profile. And since you've always got admin rights over your profile, you're effectively already running as admin. Personally, I like managing my Node.js installs using NVM because it lets me use the latest features but I also get the flexibility of trying out new things without impacting my current setup. Now there's a version of NVM for both Mac OS and Windows, depending on your platform of choice. And it originally came out for Mac OS and then someone created a port of it for Windows. They're pretty close to one another, they're not exact but by reading the help, you can figure out the difference. I'm gonna be using it on Mac OS but you're really gonna have a hard time knowing that I even am using NVM under the covers because the experience is the exact same, right? If I was using the first option, the first installation option. So I just gave you two different options for installing Node.js, one using the Node.js installer and the other using NVM on either Mac OS or Windows. So how about I show you each of these in three different demos? Just know that you only need to choose one of these things.  And with that, I'll do two demos. One of them will be with Mac OS and one of them will be with Windows. You only need to pick one of these options. You don't need both of them. And the reason why is, well, it just gets confusing if you try and do both, there's just no need to do both. You're either gonna do this one or you're gonna do that one depending on your platform. This lesson contains links in the chapters for each of the three different demos. So use the chapter link control that we have in the bottom of the video to view the chapters and to jump to a specific part of the lesson to skip portions that you're not interested in. So like for example, if you're on Windows then you may only care about the NVM Windows demo so you can jump straight to that. Okay, so let me jump into my demo. This first demo is gonna use the traditional installer download approach for getting Node installed in your machine. Now I'm showing you this on Mac OS but the process is basically identical if you're on Windows. So I wanna start by coming over here to my command prompt. I wanna show you that Node is not installed. So I'm gonna say node-v and we can see there's nothing here. I'm also gonna show npm-v to show that both Node and npm are both not installed. So what I'm gonna do is I'm gonna go to the Node.js website. So let's go over here, open up our browser and I'll go to node.js.org. And here I wanna go through and download a version of Node that we can use for the SharePoint framework. Well, in this case here, I know that version 14 is what I wanna be able to use. So I'm gonna choose LTS 14. You do wanna make sure that before you download a version to go install, a version node install, you wanna make sure that you check and you get a version that is supported by the version of the SharePoint framework that you're currently on. So I just went ahead and downloaded this version. You can always get older versions if you come over here and look at other downloads and I can scroll down under LTS and I can see previous releases and here I can see all the old versions. So like for example, if I was gonna install SharePoint framework for doing work on SharePoint Server 2019, which only is 1.4.1, which is I think Node LTS version eight is what I want. You can see here is Node.js 8.x and I can choose the latest version of Node that's available to me for version eight. So I would just grab, in my case here, I'm gonna get this package file because that's the installer for Mac. But if I was on Windows, I could grab like the x84 for the MSI for the installer. Okay. All right, so you see a couple of different options there. I'm gonna go ahead and click on this package and go ahead and start installing it. So I'll say continue, continue. I agree and then install and I'll have to type in my password. Let it go ahead and install and to that it's all been installed. So now let's go ahead and we can get out of the browser. I'll go back to my command prompt and I'm gonna open up a new command prompt. The reason why is because I need to make sure that it gets initialized. So it actually loads when the command prompt loads. So now I can say node-v and I can see now that I have node installed as well as I have NPM installed. But for now, that's it. Node and NPM are installed, so I'm good to go. Now that's, again, that's one way of installing Node and that's using the installer that's provided to us by the Node.js website. The other options are using NVMs. I'm gonna show those to you in the next demo. Now in the second demo, I wanna show you how to install Node and jump between the Node versions using the popular Node version manager utility that we have on Mac OS. Now the next demo is gonna show you the exact same thing but using a Windows implementation and that works a little bit differently. Now I already have Node installed as you saw from the previous demo.  I can leave that being installed the way it is. It's not good, it's not bad, it just, it is what it is. Now you can also install both using the installer and you can use NVM and have them both kind of installed at the same time and I'm gonna show you what that experience looks like and I'm demonstrating that because if you already have Node installed in your machine and you decide I really wanna use NVM, I'm gonna show you it's not that big of a deal. So I already have Node installed, I've already mentioned that to you a second ago but the problem is that if I try and show you it's not really giving you a good example that it's actually that I'm gonna install NVM because clearly I've already got Node installed but one thing I can show you is that NVM is not installed by typing in NVM-V. So let's go ahead and get this all installed and running. So I'm gonna come over here and launch Chrome and we'll go to github.com slash NVM-SH-NVM. All right, now let's see what the installer options are available to me, so I'm gonna scroll down, look at the installer options right here, installing and updating. So we have a bunch of different options and how we can install it. I have a scripted installer on my Mac development environment here. It's called Homebrew, just like on Windows we have a scripted installer called Chocolatey. I'm gonna use the one that we have here on macOS called Homebrew. So what I'm gonna do is come over here to my command prompt and I'll just type in brew search NVM and let's just make sure that it's available to us. Sure enough I can see that it is. So what I'm gonna do is I'm gonna go ahead and install this. I'm gonna say NVM install, I'm sorry, NVM, brew install NVM. Okay, here we can see that NVM has now been installed. So here you can see there's a bunch of other instructions and some stuff that I need to do to go set this up in my configured shell because my shell is ZSH. I'm just gonna follow whatever instructions that they tell me to do. I'm gonna spare you from looking at me having to go through all this stuff and just skip ahead and we're gonna assume that I've already done that. So what I wanna do is I wanna go ahead and open up a new terminal window to make sure that everything has been loaded in it because each time you open a new one it reloads your profile and I'm gonna type NVM-V and we can see that sure enough we do have it installed. Now something else that's a little interesting with this is that if I type in NVM-H for getting some help what we'll see is is that I can get a list of all the things that are installed, all the versions of Node that are currently installed in my environment. And we can see right there, NVM-LS. So what I want you to see is if I do NVM-LS what I want you to take notice of is that you see that I've got one called System. Well, and you can see that little green arrow is pointing to System. What that means is that I have a system installed version of Node that my machine is currently using. So if I do Node-V, I'm on 14.7. Well, that's 14.17. Well, this makes sense because just a minute ago we installed Node using the installer and when we do that, that version is referred to as System. Okay, that's fine. So now I've shown you how you can have an installer version that you get from the Node.js website to install Node, but I want to use NVM to install it. So what I'll do is I'll say NVM-LS remote and that's going to give me a list of all the versions of Node that are available to me and what it's doing is it's getting that from the Node website because it's going to download the installer from the Node website. Now a couple of things you're noticing here is these things are going by. You see these sections that say LTS with a name. So the name of the current version of Node LTS that's installed or that's available is they go by the periodic table of elements. So right now we're on Firmium and you can see the latest version of Node, version 14.17.5, that's Firmium. Well, I already have version 14.17.5 because we just saw that a second ago by doing Node-V and that's probably coming from system, as you can see. So why don't we install a different version? Like let's do 14.17.4. So I'll say NVM install 14.17.4. And so what you see here is it's downloading the version of Node that I specified and it's going ahead and installing it. And now if I do an NVM-LS, I can see I've got version 14.17.4 and I've got a system version installed as well. And furthermore, if I, let's say let's go into a new terminal and I do NVM-LS and we can see the default version is still stuck on system. That may be what you want, that may not be what you want but you can use the aliases version, the aliases tag in command with NVM. alias-h. And so here we can see alias, we can specify a specific version that we want to be able to use here as our default version. So I could say NVM alias default is 14.17.4. Right, so now that that's done and I say NVM-LS, I'm still on system but if I open up a new terminal and I say NVM-LS, you're gonna see that now my default is going to 14.17.4. So that's cool, I've got all these different things that are set up, we can even see all these other aliases that have been set up. And these are really cool because you can use this to create a little mental checklist. So like for example, let's say that I wanted to set up a version of Node for working with SharePoint 2019, which is on-prem. Well, SharePoint 2019 only supports up to SharePoint framework version 1.4.1. And if I refer to the docs as I've already talked about with our throughout the course so far, that means that we can only use Node LTS version eight. Well, I can see here that the version eight of that is carbon that you see listed right here. So what if I went and did NVM install LTS carbon? That's an alias, so that's gonna go and download Node V8 17.0 and what that'll allow me to do now is now I'll have two different versions of Node that are installed, one version 14 and one version eight, but watch this. What I can then do, so I have NVM-LS, we see a couple of different versions listed, what I can now do is have an NVM alias set up for SP 2019 and I'll have that point to LTS carbon. And now when I do an NVM-LS, I can see that I have an alias there called SP 2019. So I could go to NVM use default, which remember I specified that a minute ago to be my Node version 14.17.4. So right now, NVM-LS, what am I on? I'm currently on 14.17.4, but I could also say now I'm actually gonna do development for that customer that's SharePoint 2019 on-prem and I could say use SP 2019 and it'll switch me over to Node V8.17.0. So now let me show you a little bit of the power of where NVM is really coming into play here and what makes it so useful. It's not just being able to have these different Node versions I can jump around with, but it's being able to install packages globally and specific versions of those packages globally inside specific versions of Node. So we haven't gotten to the point yet to where we can install all the other tools that we need for SharePoint framework development, but I wanna prove the point to you here. If I went in, so right now we're on NVM-LS, what are we on? We're on version eight right now. We can see that like this and I can then ask Node, I can use NPM to say what packages do you have installed globally? And I can do that by saying NPM-list-g that says what is everything that's installed globally or I can do dash-global like that make it more wordy and then I can say I only wanna show things where the depth is equal to zero and what that's gonna do is that's only gonna show me everything that's installed globally that I've installed, not things that are maybe additional dependencies underneath the thing that I installed. So if I installed package foo and foo required bar, then if I said depth equals zero, it's only gonna show me foo. If I didn't put that depth equals zero on there, it would have just said foo and bar, here's all the stuff that's installed. I don't care what dependencies are installed, I only care about the stuff that I've installed. So let's install something globally and show you how I can jump around. So let's say I wanna install a version of TypeScript and let's go back to TypeScript version two. So what I can do is I can say while I'm under node version eight, I can say NPM install globally TypeScript and I can specify a specific version by doing an at and then put that two on there. But there's a couple other cool things we can do with this. Let me just show you a couple of little node tricks. What if I did a NPM info on TypeScript? So it's gonna take a second to query the NPM registry and I can see that the very latest version is 4.3.5 but I know there's a lot of older versions that are up there as well. So to see all the older versions, I can put in versions on the end and it's gonna give me this huge list of all these old versions. So let's say, okay, there we go, there's two.9.2. So let's go install 2.9.2. So I'll do this by saying NPM install TypeScript at 2.9.2. So the at sign after the package name with a version number installs a specific version and I'll say install that globally. All right, cool, so that's done. So now let's go back and let's do NPM list dash G depth equals zero. So we have installed both TypeScript version two and we have NPM version six. Now, notice the path that it's listing right here above it. This is my profile. There's a hidden folder in there called .nvm and then in there, I've got a version slash node and there's the version of node that I have installed and then I have a slash lib folder. That's where all my global packages are installed. Well, let's jump out of this. Let's go to my other node install and let's see what's installed there. So NPM use default, that was version 14. So I'll do the same thing. Let's do list G depth equals zero. He only has one thing installed, NPM. I can install TypeScript and I'll just do at latest because that's a tag that's gonna say get the latest version dash G. I'll go ahead and install that. Now remember, I'm installing this in my node version 14 install that I installed within VMs. Now I can say NPM, let's do node dash V or version 14, NPM list G depth zero. TypeScript version four. Again, NPM use SP 2019, do the same command and I can see it's TypeScript version two. You can't do that stuff when you have a version of node that you only got from the downloader or the installer from the Node.js website. That's one of the reasons why I love this NVM tool and I really think you should check it out. NVM is not at all required for doing SharePoint framework development but I do think it's a powerful and very useful utility when working in nodes. So I wanted to show it to you in this course. I've only shown it to you at Mac OS which is where it really originated from but due to its popularity, there are some Windows clones that have been created as well. In this demo, I want to show you how to install node and jump between node versions using a node version manager utility on Windows. So we're gonna start by jumping over to my Windows environment and I'm gonna go to the NVM for Windows project. So that's just gonna be at github.com slash Corey Butler slash NVM dash Windows. All right now, this may look a little bit different based on when you go to download NVM for Windows because the project may have been updated since the last time we actually tried this. So what I'm gonna do is I'm gonna scroll down on this page and I'm gonna find the part where it talks about installing and we have an installer right here. So I'll say go ahead and download the latest installer. So here's the list of the installer or the list of the releases and we should find, there we go, there's our NVM setup.zip. So I'll go ahead and download this and then we'll open the file up and then I'll go ahead and double click on it and start the install. All right, so I'll say accept the agreement and go next, next, next, next install. So just go ahead and let this install. Okay, once it's installed, go ahead and go to finish. Now that it's installed, let's go ahead and open up our command prompt. So I'm just gonna open up a cmd.exe and let's just say NVM, let's see what happens. So we can see that NVM is actually running. We can see we got version 1.1.7. Let's make this a little bit bigger, there we go. And we can also see a bunch of other commands that we have access to. So let's do NVM list to see a list of all the node installs that we have installed. And here you can see that I have no installations that are recognized. So the first thing we wanna do is go ahead and install some. Now notice here that we've got this available flag that we can add into it. So I'll just do the same things, I'd say available. And now it lists out all the versions of node that are available for installation. So here I can see that we've got version 14.17.5. And for the command prompt to go ahead and install this, you can see if I go back up to the top here to install one, I just say NVM install and then I pass in the version number. So let's go ahead and let's say NVM install 14.17.5. And so what that's doing is it's downloading and it's installing node version 14.17.5.  It's actually cut off a lot of the older versions, like say from version 10. So let's just see if we can grab, let's see what version 10 is available for us because that's something we could use for SharePoint Server 2019. So I'm gonna go ahead and copy that value and let's come over here and get a list. And I'm gonna do a search for the 10.... Let's see, there's latest 10.something. Let's see what else we have here. So here's a bunch of other versions that we have listed. Scroll back up a little bit. And what I can see is probably the latest one is 10.24.1. So that's the one that we're gonna wanna grab to have two different versions of node install. Okay, so now I can go see a list. NVM list, see what's installed. We see it's 14.17.5. So if I do node-v, oh, we see it doesn't understand anything yet. Well, that's because I need to actually switch over to that version. And you can see that, but it's listed right here for NVM use. So I'll say NVM use 14.17.5. And then I'm gonna say node-v. Okay, cool. So now I can see that we're actually running inside or we have node installed and we're node 14.17.5. So we have node 14.17.5, but let's go ahead and install another version of it. So we have 10.24.1. So I'll say NVM install 10.24.1. And so it's doing the exact same thing. It's downloading a different version of node and it's going about installing a different version of node as well. So we'll give this a second to finish. Cool, so now we have two versions of node installed. So I can say NVM list. We have two versions. We've got 14 and we've got 24. So again, I can say node-v to give me the current version I'm running. We see I'm running 14.17. But I can switch over and say NVM use 10.24.1 and do the same thing, node-v. And sure enough now I'm running 10.24.1. So it's a really quick example, but I just wanted to show you how easy it is to get NVM installed on your Windows machine and have that ability to jump between different node versions. Now for those of you on Linux, well, if you're on Windows using the WSL2 command or your own Linux, you're gonna need to install one or more prerequisites after installing node. It doesn't matter which option you choose or which one you elected on how to install node. This is gonna be required regardless. So if you're using WSL2 command prompt, you're gonna need to install the build essentials package and you can do that using the command sudo apt-get install build essential. Now this package is needed in order to create a developer certificate. And that's gonna be done in a later chapter when we start creating our very first projects. You may also need to do this if you're also working on a Linux environment and not just WSL2. Okay, so that wraps up my discussion on node. In this lesson, we got Node.js and NPM installed on our machine. And I showed you how to install Node.js and NPM with the installer from the Node.js Foundation website as well as how to use NPM on either Mac OS or Windows to have a little bit more control over your installation. So with all that done, we can start installing the tools that are gonna make up the build tool chain. So I will see you in the next lesson while we do that. Hey, welcome back. In this lesson, we're gonna look at Yeoman. The SharePoint framework is just a well-organized folder of texts and files. The tools that are provided by Microsoft to build and package the source files into what is deployed in the SharePoint expect specific files to be present in very specific locations. So to help get the project structure just right as well as grab all the necessary dependencies, Microsoft is using the tool called Yeoman. Yeoman helps you kickstart new projects with a simple command line tool by simply running yo and the name of the generator, Yeoman will ask you a few questions before building out the project scaffolding. This ensures that you have the same starting point with every SharePoint framework project. Think of it as an alternative to Visual Studio's file new project dialogue if you're coming from a traditional Microsoft development background. Yeoman is built on top of Node, which means that it's cross-platform and it works the same way across Mac OS, Windows and Linux environments. In fact, you're going to install Yeoman on your machine as a global NPM package. And you're going to do that using the NPM install-g option. Yeoman is just the engine because once it's installed, you then need to get a generator. A generator is a plugin that you run with Yeoman and Yeoman knows how to ask specific questions before creating the project scaffolding. So Microsoft created the generator for the SharePoint framework that they've published for our use. And this is what you will use to create new client-side web part projects. The generator is a Microsoft scope package named app-microsoft-generator-sharepoint. You'll install this the same way you installed Yeoman as a globally-installed NPM package. So you do the NPM install-g-yo and then you're going to do the exact same thing but you're going to specify the app-microsoft-generator-sharepoint package. Once it's installed, running it is as simple as just typing in yo at microsoft-generator-sharepoint to go ahead and get it kicked off. You can do that from the command line. The generator is first going to ask you a few questions about your project and then it'll scaffold the project by creating the files and folders that you will need based on the questions that you answered. After the project structure is complete, it'll then run NPM install to download all of the packages as dependencies that are referenced in the projects-package.json file. This includes things like build toolchain dependencies, gulp tasks that you'll use and other libraries that you need to get started. Now you'll see there on that last option there, there's a special flag. You can tell the generator to avoid that last step of downloading all the packages by including the flag skip install or dash dash skip install. This is useful if you want to defer downloading all the packages later or if you want to use a different package manager other than NPM. Now indulge me for a minute while I explain something that I've noticed since I originally published this course that it seems to keep confusing SharePoint framework developers even after four years. The version of the SharePoint framework is not directly tied to the version of the SharePoint framework generator that you use to create your project. The generator's job is simply to scaffold a new project. Part of that includes creating the package.json file that contains the references to the version of the SharePoint framework the project is gonna use. The key point here, the version of the SharePoint framework used within a project does not have to match the generator's version. This is really best understood if you look at a scenario if you're developing for SharePoint 2019, SharePoint Server 2019. Remember that SharePoint Server 2019 only supports SharePoint framework 1.4.1. Now you can use any version of the generator starting with 1.4.1 going all the way up to 1.10 to create your SharePoint framework 1.4.1 projects that can be used in SharePoint Server 2019 on-prem. In fact, you really should use the most current version of the generator because that ensures your project is using the most current project scaffolding that may include bug fixes that are not reflected in the code that's generated by older generators. It's important to note this is just one use case. In fact, the generator, the common generator for SharePoint framework doesn't even need to be installed to develop a SharePoint framework project. You can get a project created by a friend and provided you've got node and gulp installed, you can continue your work on the project. The key point that you need to take away from this is that the installed generator version doesn't have to match the version of the SharePoint framework that's used by your project. Okay, let's do a demo and let me show you how we get everything installed and working and make sure that it's all set up. Okay, let's get this working. In this demo, I wanna show you how to install and configure the two required tools on your developer workstation for local SharePoint development work. Now, I'm gonna do this in my Mac OS environment, but again, everything that I do, everything I run on the command line and the tools that I install, they're all required and they work the exact same way if you're in a Windows environment. So I'm gonna start by opening up a command prompt on my machine. So I'm gonna do that by launching hyper. So here's my environment and I'm gonna first check and see what global packages have been installed in my environment. So I'll say, what version of node are we on? Let's just make sure we have node installed. We do, we're on version 14 and let's see what packages are installed. So I'll say npm list g depth equals zero. Let's just make sure that yeoman is not installed just yet. So we can see it's not, I've just got npm and type script that are installed from our previous demos. So let's go ahead and let's install yeoman. I'm gonna do that by saying npm install yeoman global. And again, I could do the dash g or dash dash global to get the shorthand version of it or the shorthand command. Global works for both of them. After this gets installed, I'm gonna go ahead and test down and make sure that yeoman is there. All right, so now that yeoman's installed, I'm gonna go ahead and just say yo and let's see what happens. So we can see here that yeoman is fired up but it really doesn't know a whole lot of information here. It's a bit basic and that's because it's not really designed to run like this. What it really needs is a generator. So now it's prompting me to install a generator. So I'm gonna go ahead and quit out of this by just hitting the control C a couple of times. So the next step is gonna be to install our SharePoint framework generator. So I'm gonna do that by saying npm install dash g at Microsoft slash generator dash SharePoint. All right, after the generator is installed, now I can execute yeoman by just saying yo and I should see my generator is listed which there you can actually see that it is installed and it is available to me. So I'm gonna not run it this way. I'm gonna go ahead and exit out of that. Instead I wanna run the generator to be very explicit. So what I'm gonna do is I'm gonna jump into another folder and generators typically expect to be doing their work within the folder where they're gonna be doing their project scaffolding. So what I'm gonna do is I'm gonna create a new folder. We'll just make directory for first spfx and then I'm gonna jump in there and then I'm gonna go ahead and run generators. I'm gonna do that by saying yo at Microsoft slash SharePoint and let's do the skip install. This last primer as I explained before is gonna bypass installing all of the npm packages after I scaffold up the project. So this is where the generator is gonna ask me a bunch of series of fairly simple questions that are pretty self-explanatory. I'm just gonna keep things simple now and I'm just gonna go ahead and accept all of the options that it gives me and just take all the defaults. Now in just a few seconds, you can see the generator has now scaffolded up the project. You can see it only took a few seconds for me to answer those questions and I got a project created. Now remember, I skipped the part where npm install is run at the very end. So now I can open up my project in VS Code by just typing in code dot and it's gonna open up the project inside of VS Code. Here we can now see the folder that contains all the stuff about our project, including if I go into source web parts, I have our web part class that you see listed right here. Now, let me go back to the scaffolding here. I wanna show you something. SharePoint framework projects have a lot of dependencies in the form of npm packages. So you'll need these in order to build, run and test your client-side web part. So let's go get all the dependencies by running the npm install. So I'll do that by coming back over to my console and saying npm install. This is gonna take a minute or two for it to complete. But while we're waiting, it's worth pointing out that this is where this style of development differs from what traditional SharePoint developers are used to. In traditional SharePoint development, you installed Visual Studio, which took you quite a long time and then you also installed some extensions for Office and SharePoint development. In that approach, you get everything you need for all the projects upfront before doing any work. But with this approach that I'm showing you here, that node-based development flow, that is each project gets its own scaffolding. And again, like I said, love it or hate it. It is what it is and I just wanted to show you and make sure that you understood why you had to do this process. All right, now we've got our project all set up here and we've got this node modules folder that has now been populated. So what I wanna do is let's come over here and let's take a look at the folders that have been set up here.  These are all the dependencies for a SharePoint framework project and it's all of the dependencies, dependencies, and their dependencies and their dependencies. So there's quite a lot of stuff in here. Now remember, yes, you're gonna have that in each project, but you won't ever check that node modules folder into your preferred source control system. You're gonna treat that just like you would the packages folder in a .NET project. It is not added to your source control and the first time you get a .NET project from source control in your machine, you usually run the package restoration process. It's the same thing we're doing when we run NPM install. Okay, that wraps up my discussion on Yeoman. You've learned what it is, why we needed, along with the SharePoint framework generator and saw how to install it as well as how to run it. So now join me in the next lesson to continue our build tool chain discussion and make sure that your developer environment is all set up so that we can start building things for the SharePoint framework. Hello and welcome back. In this lesson, we're gonna look at TypeScript, the supersetted JavaScript that you'll write your SharePoint framework projects within. I'm also gonna include some resources that'll help you be more productive as a TypeScript developer in the discussion. So let's get started. The SharePoint framework projects are client-side projects which means they run in the browser. And that means that all the logic is implemented in JavaScript. JavaScript can be challenging for some of it, for some people, due to its part and its loose rules. You know, the fact that you can actually add strings and numbers together without getting errors, compiler or runtime errors. So in an attempt to address these challenges with JavaScript and make it a better option for large projects, Microsoft introduced TypeScript. Now TypeScript is a superset of the JavaScript language. The idea was to make large JavaScript projects much more manageable.  One feature, the one that actually gets the most attention is the fact that it introduces types to JavaScript. With TypeScript, you can declare variables of strings or bullions or numbers and you can also create classes and interfaces and enums. You can even give functions return types. These capabilities, they help you catch errors in your code at design time, rather than with plain JavaScript where you might not catch the errors until runtime or, well, until you actually use the app. For instance, if you try to add a number and a string in JavaScript, you won't get any errors or warnings when you write the code. But when you run the code, it won't give you any errors. But when you look at the behavior of the app, you might find that adding the string SharePoint to the string 12345 yields SharePoint 12345. Is that really what you wanted? With TypeScript, even if you didn't specify the types, you will get an error or a warning when writing the code saying that the types don't match. This helps you find issues in your code earlier in the development process. So you run TypeScript in the browser? No, no, you don't do that at all. The TypeScript you write will be transpiled down to JavaScript and unlike compiling, which takes source code and transforms it into another language, transpiling converts it from one language to another language. And they both have a similar level of abstraction. Unlike other tools that we're using in our development tool chain, we don't need to explicitly install TypeScript. TypeScript is referenced by the packages that Microsoft includes within the default scaffolding that's defined by the generator. So therefore, the first NPM install that you run on your SharePoint framework project will get the compiler. And with that being said, you might be like me and have a globally installed instance of TypeScript on your computer. But regardless, since it's part of the dependency chain in the SPFX dependencies, you'll also get a local copy. Now, TypeScript is a huge topic to tackle, but I don't want to spend too much time on it in this course. There are countless courses and resources that are out there for it, such as the official site I've listed at the top of this slide. I also strongly recommend this online book by a gentleman by the name of Basarot Alsaii. You can download an electronic copy or just bookmark his ebook, which he updates when new features are updated. It's one of my favorite resources for TypeScript. Now, while I won't spend too much time diving into the details of the TypeScript language, I do want to spend a couple of minutes on something called a type declaration. A key point to remember is that types in TypeScript are entirely optional. If you don't want to use types, you don't have to. You can configure your code lenter so that it doesn't warn you when coding about missing types. There's also the any type, and that's just the easy way of typing something and saying it can be anything. In fact, if you don't include a type on an object, the compiler assumes the any type is implied if your compiler is set up that way. If you don't like that implicit any type, you can set the non-implicit any compiler flag to tell the compiler to flag whenever it sees an implicit any to flag it as an error. And also keep in mind that the errors, they're not going to keep you from transpiling your JavaScript to TypeScript. The TypeScript compiler while throwing type errors will still transpile the code to JavaScript. Then you can use that because remember, even TypeScript code that has errors has type errors that still valid JavaScript. Now, what about the parts of JavaScript like the two string function or the window DOM object? TypeScript ships with this thing called the lib.d.ts file and that contains all of the ambient declarations for various constructs present in the JavaScript language and the browser DOM that you're going to come across. Wait a minute, ambient declarations, what's that? Well, when you write your own code, you define all of the types for your own objects and methods, but what about when you want to use objects or methods from someone else's code?  What an ambient declaration is, these are promises that you are making with a compiler. They're like documentation. They describe the types in external libraries so you can get context on those objects in your code. These ambient declarations are defined in type definition files which have the file extension d.ts. More recently, we've seen more and more projects include these files in their libraries which makes life easier for developers by consuming these libraries. They do this by including the type definition in the package and referencing the type definitions in the typings attribute in the package.json file. This way, there's nothing to go grab. You just see this in the popular, you can see this in the popular date library called Moment.js. But what about the cases where you need to go get type declarations for libraries that don't include them? So early on, a community-run project popped up that became very popular. It's called Definitely Typed. And it served as a repository of sorts for ambient type declarations that typescript developers all contributed to. So how do you use these in your projects? Well, initially, we had a tool or a couple tools by Definitely Typed called TSD. And it was a command line tool that you used to search, download, and update your type declarations in your project. It pulled type declarations into your project for you. But a couple of years later, a new tool came out as a successor to TSD called typings. And this made working with type declarations much easier, as it used a similar syntax as NPM, which we were used to in JavaScript and TypeScript projects. But both these tools, they had fundamental flaws. They required you to install yet another global tool in your workstation to get these type declarations. Secondly, they stored a manifest in your project that listed all the type declarations that you were using. And this was used to download the type declarations of another developer was working on the project. Look, these two options, they worked, but it was just a bit annoying. And it was really just made it harder than it really should have been. So thankfully, the TypeScript team in TypeScript V2, Microsoft ended the madness. TypeScript version two introduced this thing called an at types scope of an NPM package. And it also introduced a project that monitored the definitely typed project and it would take type declarations and publish them as individual NPM packages to the NPM registry. For instance, if we had type definition named for jQuery and the definitely type project, we would get an NPM package named at types slash jQuery. And now instead of needing a special tool, we can install the jQuery type declarations using the command NPM install at types slash jQuery. You would also want to put in this extra flag on the end called save dev. And what that did is that told NPM to save this package and the dev dependencies part of our package.json. So what this did is it eliminated the need for some special tool to download and manage type declarations as well as a special type definition manifest file. Now we can search for these types using the at types prefix in the NPM registry, but we can also use this cool site that Microsoft stood up, that I've linked to here. The site will search for NPM packages that have type declarations either bundled or on definitely typed. And these changes have greatly simplified the use of our type declarations in our projects. So if you have at least TypeScript V2 installed in your workstation, there's no need for TSD or typings anymore unless you've got an older project that hasn't been updated to move its type declarations as scoped at types projects within the package json. Now, another thing I want to point out, you may see folders and sample SharePoint Framework projects or early screenshots from early on in SharePoint Framework's development that includes these files and folders of typings and TSD, et cetera. These things are obsolete. As later versions of the SharePoint Framework Yeoman Generator stopped adding them to our project scaffolding. But you may see some throughout this course from demos that are originally created before we got to that point and that haven't been refreshed yet. Okay, so that wraps up my discussion on TypeScript and getting our code into JavaScript that runs on the server. In the next few lessons, we'll look at the tools that we use to get things running and deployed. So I'll see you in the next lesson. Hey, welcome back. In this lesson, we're gonna talk about another key part of the SharePoint Framework build tool chain, is tools called Gulp. Now, in the introduction, I briefly mentioned a TaskRunner tool called Gulp and most developer environments have some sort of a TaskRunner. You might have heard of tools like Make or Grunt or well, those of us with a Microsoft background, I'm sure you're familiar with MSBuild. These TaskRunners, they help us perform actions like linting and copying and moving files, compiling, deploying, launching tests and debugging tools among a lot of different other things. Gulp's another one of these TaskRunners that is very popular. It runs tasks that you create, tasks that are defined using JavaScript. And this is the TaskRunner that Microsoft selected for working with SharePoint Framework projects. Now, Gulp prefers code over configuration for defining tasks. This differs from tools like Grunt and MSBuild that prefer configuration over code. What do I mean by that? Well, MSBuild, these tasks are defined using XML, which instruct the build executable what to do. This approach is kind of limiting because it only limits you to be able to perform the operations that the TaskRunner supports. That's referred to as configuration. If I try to define something in an XML file and MSBuild hasn't been coded to look for that thing that I've defined, it's not gonna happen, it's just ignored. Gulp's approach of using code instead of configuration provides a minimal API to create tasks that I write in JavaScript that can do anything that you could express in code. Gulp is also very fast because unlike other TaskRunners, it doesn't write intermediate files to disk while it's working on those tasks. Instead, it leverages node streams to keep files in memory to avoid a lot of the IO when working with the disk. The tasks you write can leverage plugins or reusable bits of code other developers have published in that platform for common tasks. For instance, there's a plugin for processing your less code or SAS code files to CSS, another for merging all your CSS files into a single file and yet another for minifying the resulting file. Gulp and all of its plugins are built on top of Node.js and just like other tools in the SharePoint framework tool chain, there now that means that they're also gonna be able to take advantage of being cross-platform. And just like the other tools in our SharePoint framework tool chain, you install it in your machine as a global NPM package. And you're gonna do that by specifying NPM install dash G and then Gulp. Now let me take a minute and let me explain the difference between two very distinct versions or flavors of Gulp. There's Gulp and there's Gulp CLI. You see the CLI here listed on the slide for what you would install. Gulp, the team that was behind Gulp was making a lot of architectural changes and improvements to Gulp when they were moving from V3 to V4. But one of the things that they also made a decision of was to drop backwards compatibility with older versions of Node. Gulp just wasn't gonna be compatible with older versions. And this happened right around the Node.js V12 release. So what Gulp did is they said, if you're using a project that's leveraging or using Node version, anything less than version 12 or anything prior to version 12, you should use Gulp V3 because Gulp V3 is not supported on Node.js V12 and higher. And Gulp V4 is not supported on older versions of Node. It's only supported on Node V12 and higher. Well, one of the challenges that we had is that because we're also installing Gulp at a global level in our machine, if we installed Gulp V3 or V4, that's gonna exclude us from using newer or older versions of Node. So what Gulp did is they released another project called the Gulp CLI. That's intended to be what you install globally on your machine. You should install a Gulp-CLI, as you see here on the slide. And then in each one of your projects, it's gonna have its own version of Gulp, either V3 or V4, specifically in the context of the SharePoint framework, it's gonna be Gulp V3 or V4 based on the version of the SharePoint framework you're using that also supports specific versions of Gulp. So the thing I really wanted to highlight here and I wanted to point out with this extra little comment is that when you're installing globally, make sure you put the install the Gulp CLI version globally. You don't have to worry about installing it in your own individual projects because those will all get the proper version of Gulp. And if you're a somewhat experienced version or developer to the SharePoint framework, you know that the SharePoint framework developer documentation did not call this out. That was updated at a later date. So if you look today at the SharePoint framework developer documentation, you will see that the instructions are to use the Gulp CLI because that is intended to work with all versions of Gulp, regardless of what your project's using. So you can have a developer machine that can be used for different versions of Gulp. Now, let's talk about Gulp specifically in the context of SharePoint framework. Microsoft created many different tasks for the SharePoint framework that are all published as NPM packages. These packages, they're referenced in the package.json file that the SharePoint yeoman generator is gonna create for us. So that means that they'll be downloaded into your project the first time you run NPM install, which is actually run by the generator. That means there's nothing extra for you to install at this point. In just a moment, I'm gonna show you how these tasks are loaded into Gulp for SharePoint framework projects. Now, the way they load projects, it's quite unique when you compare it to how most other people use Gulp, but for better or worse, this is how Microsoft has chosen to do it. Now, if you're interested in creating your own Gulp tasks for your project, check out the chapter on creating Gulp tasks in the ultimate bundle of this course for more details. And I've got some scenarios and some other demos that show how to go about doing this, where we extend Gulp to do some pretty interesting things. All right, in this demo, I'm gonna show you how to install and use Gulp, which you're gonna use around development, building, packaging, and deployment tasks. I'm gonna do this in my macOS environment, but again, everything I do, everything I run on the command line, they're all required and they work the same way for Windows. So I'm gonna start by launching a command prompt to show that Gulp is not installed, and then I'm gonna install it. So let's come over here and let's go to our command prompt and I'll say npm list-g depth equals zero. All right, so here we can see Gulp is not installed. So what I'm gonna do is I'm gonna say npm install Gulp-g and that's gonna install Gulp in my environment.  That's something else I need to install on my machine, but it's not important for this demo. So what I'm gonna do is to show, let's show that Gulp actually got installed. So I'm gonna do an npm list-g-depth equals zero, and sure enough, we can see that Gulp was installed. Now, let's see how this is gonna be used. Let's go back to the project that we created in our previous demo when we worked with Yeoman, and that was called our first SPFX. And let's go ahead and open that back up in VS Code. So if I open that up in VS Code, and I look at the file called gulp-file.js in the root of the project, what we can see here is we can see how Microsoft is actually initializing Gulp. Now, the Gulp object that you see you don't really, you only see it listed right here, whereas it says require Gulp. All of the other stuff that you see here in this file are is Microsoft, when this Gulp file.js is gonna be run, which is what Gulp is gonna run on our project the very first time. When it runs all of this, effectively what it's doing is it's saying, go find this package here, the SP build web package, and it uses that to load all of the Gulp tasks that Microsoft has created for us. And it's gonna go through and initialize it inside of the Gulp utility here. So that's how we're gonna get all these tasks that are gonna be defined in our project. We don't have to go create these guys, these are already created for us. So now if I come over here back to my command prompt and I do gulp-tasks, that's gonna list out all of the tasks that Microsoft has initialized and is part of my project. So here we can see a lot of them. We can see clean, build, default, bundle. Build is gonna take all of our SAS files and transpile them to CSS, all of our TypeScript and transpile it down to JavaScript. The bundle is gonna use webpack to package everything up. And we have a bunch of other ones that are listed there. They're not really important to look at right now. But see, that's all that stuff that's done. That's all, we have all these different tasks now that are available to us in Gulp. And I just wanted you to see how these things are all getting loaded into the Gulp process. Okay, that wraps up my discussion on Gulp and the demo of actually getting it up and running. But that's that last part of the tool chain that I need to cover in this chapter. We got some more stuff to do, so I'm gonna see you in the next lesson so we can finish off our discussion and get building stuff pretty soon. Hey, welcome back. In this lesson, we're gonna talk about webpack. This is a critical and yet mostly invisible tool in the SharePoint Framework Development Build Tool Chain. And you'll see what I mean by that as we get to the end of this lesson. The SharePoint Framework Customizations run client-side, which means they're based on JavaScript. And just like server-side projects or SharePoint Framework projects consist of multiple source files. Modern JavaScript development has evolved to adapt concepts such as modules that handle dependencies between different components. And the challenge is that modules weren't a native concept in the browser's JavaScript engines initially. So not all browsers knew how to handle modules. And while there are many different ways that you can address this challenge, the way we do it now with the SharePoint Framework is with something called Webpack. Webpack is a module builder that runs prior to packaging your SharePoint Framework project and it runs right after the build tool chain transpiles all the TypeScript to JavaScript. If you're familiar with Webpack, you know that you can actually do that as part of the build process, but that's not how they've selected to do it. They instead build all the JavaScript first and then they run Webpack. It doesn't matter, it's transparent to us. You know when you run the command Gulp bundle on the command line? That's when Webpack is actually running. What it does is it takes into consideration modules with dependencies and pulls them all into a single file. Now there are a couple of details to this that I'm skipping over here. For instance, it doesn't suck everything into the bundle as you're gonna learn about in the chapter when we talk about leveraging external files in libraries. You can actually tell Webpack, say don't pull that external bundle or external library into my bundle, instead reference it from a CDN. Or as you'll learn in the chapter in the ultimate bundle, we're about customizing and extending Webpack. I'm gonna show you how you can use code splitting tools, how you can, the code splitting capability in Webpack to split your code into multiple bundles so that some bundles are only downloaded on demand. Like if you had a web part that had a complex property pane, you could put just the complex property pane in one bundle and it would only get loaded by the user in the browser when the property pane opened up. Now in addition, this bundling of assets isn't limited to just JavaScript files. Webpack can also bundle CSS files and images like PNGs or JPEGs. Webpack differs from some of the other module bundlers in a few different ways. One thing it can do is code splitting as I alluded to a moment ago. This is the process of breaking things into multiple chunks. So like I said, maybe you want a bundle that contains all the vendor JavaScript that you're using like jQuery and React while another bundle has just your application code. Or maybe you have a big application and you want it broken into multiple bundles so you can lazy load one part only if the user goes to that part of the app. This is where code splitting comes into play. As a footnote, that example of how we would want to put jQuery or React in a separate bundle. Don't worry about that for the SharePoint framework. That's not really relevant because jQuery or React is always on a SharePoint page because the SharePoint framework uses it.  You're not gonna put that in a bundle. That doesn't make sense. We'll talk more about that when we get to the external files and libraries. That chapter's in the fundamentals bundle. Now, Webpack also introduces a concept of a loader. A loader can transform code prior to building it. Now, a loader could transform a markdown file or a CSS file to HTML for inclusion in your SharePoint framework components rendering. Think about a web part with a help file written in markdown and displayed in the property pane. The other aspect you'll find useful Webpack are plugins. These let you extend Webpack to meet your needs. For instance, you can have a plugin that minifies your code, removes duplicate code, or does other things to your code as part of the bundling process. You can learn more about these different topics on the chapter on customizing and extending Webpack that I have in the ultimate bundle. Now, like so many of these other tools, Webpack is built on top of Node.js. So that's what's making it cross-platform. But unlike the other tools that we're using in our development tool chain, we don't need to explicitly install Webpack. Webpack is referenced by the packages that Microsoft includes as dependencies within the default scaffolding that's defined by the generator. In addition, Webpack's bundling process is controlled using a JavaScript configuration file. Microsoft's build process is creating this file in memory and it's doing it during the build. So there's nothing for us to do. However, if you're interested in customizing Webpack for your projects, again, check out that chapter that I talked about in the ultimate bundle of this course because I go through a lot of different customization scenarios and demos in that chapter. Things like showing how to take your source maps and include them in the bundle that get shipped with SharePoint so you can do better client-side debugging, among other things. Sorry, Marco. Okay, that wraps up the discussion on Webpack. I've got one more thing to talk about in this chapter before we wrap up. So let's get to it and jump in the next lesson. Hello and welcome back. Okay, last lesson of the chapter. I wanna take a minute. I wanna talk about our developer environment options. If you're a traditional SharePoint developer used to using Visual Studio in .NET, this is really for you. The last thing to cover in this chapter is using either an IDE or an editor. And the difference is that an IDE is an integrated developer environment, whereas an editor is just a text editor. An IDE are things like Visual Studio from Microsoft, JetBrains is WebStorm, Apple's Xcode. They're big, they're expensive developer environments that contain things like wizards and dialogues, tool windows and visual designers. The other option is to use an editor, something like Notepad or Notepad++, Sublime, Atom or VS Code. And what you use is really up to you. I'm not gonna tell you that one is better than the other one, but in this course, I'm using VS Code by Microsoft for a few reasons. Well, first of all, it's free. You really, you can't beat that. And second of all, it's got stellar TypeScript language support. Third, it's extensible with a huge marketplace of free extensions. Fourth, it's the editor that Microsoft uses in all their demos and tutorials for the SharePoint framework, so it's familiar. Fifth, it's cross-platform. So regardless, if you're on macOS, Windows or one of the brave souls using Linux as their workstation, the experience looks the same when I show you the demos in this course. And finally, well, I love VS Code. I use it for everything, not just development and my general text editor. Okay, that concludes this chapter. We've covered quite a bit throughout this chapter. So by now, your developer environment should be set up to start developing with a SharePoint framework. That includes your SharePoint online development or SharePoint online developer tenant and your local environment, your laptop, that should be set up for doing SharePoint framework development. That's what we're gonna start doing in the next chapter. There's quite a few topics that we can cover when it comes to your developer environment, your process, and your development workflows. And the ultimate bundle of this course, I've got chapters that talk about things like doing team-based development with the SharePoint framework, implementing continuous integration and continuous deployment, CINCD, into your projects, as well as incorporating automated testing into your projects. But for now, we're in a good spot to start building stuff. So join me in the next chapter and we'll start working with the SharePoint framework in a lot more depth. Thanks for watching. And if you enjoyed this video, please click that thumbs up and the big red subscribe button below to get more of my SharePoint framework educational content as I publish it. And this video is one of the chapters from the free starter bundle of my Mastering the SharePoint Framework course by Boitanos. And you can find the other free videos from the starter bundle that are listed in the description below. That course contains over 35 hours of in-depth explanation and instructor-led demos teaching you everything about the SharePoint framework to become a master. I offer this course in three different bundles, the starter bundle that this video was part of, as well as the fundamentals bundle and the ultimate bundle. Each of these bundles contains more content than the previous bundle and some additional resources like mastermind groups and regularly scheduled office hours. You can learn more about the course on our site that I've linked here or by clicking the link in the description below the video.