This post is just one part in my 10-part email course Understanding the SharePoint Framework Development Toolchain which you can subscribe to and get delivered straight to your inbox.
Yesterday’s installment in this series covered what tools and frameworks were required to do SharePoint Framework development. I didn’t stop there, I also drew some parallels to the tools you are familiar with as a traditional SharePoint or .NET developer.
In today’s installment I want to switch gears a little bit and instead of talking about each of the different components that make up the build toolchain, I want to simplify things a bit.
I get that there are a lot of people who get big eyes and ask “why do we need all this stuff?” or say “I don’t want to learn a whole new platform like Node.js just to do SharePoint development!”
Look, I get it… and frankly I think Microsoft could have done a much better job in explaining this from the start, but they didn’t nor have they done a good job of clearing it up.
So in this installment, I want to take a minute and tell you what you need to know and what you can ignore as part of this build & development toolchain.
Let me start by saying you do not need to become an expert or well versed in all these things. While you may need them, some you can install & ignore they are even used.
In my opinion, you only need to be versed and how to use NPM and TypeScript. You need to get familiar with TypeScript as that is the language you will be writing and as for NPM, you need to get familiar with it as that’s the tool you will use when you want to update your toolchain as well as find, install and update external libraries you are going to use in your projects.
But forget about things like Node.js, Yeoman, 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 Microsoft provides to run & configure them for you.
At least that’s the approach I take when teaching this. There are a few commands you need to learn on how to run tasks with gulp or kick off a yeoman generator, but I would not consider that really learning those tools.
Let me explain why I say this.
You need to know NPM and how it works for one simple reason: you will use this in every single project to acquire, manage and upgrade dependencies in your SharePoint Framework project. It has become the standard for reusable package and Node.js package distribution for web developers.
Sure we have NuGet, but it wasn’t until recently that NuGet was supported off a Windows environment… and that support is quite limited at that. Plus, NuGet can only handle package distribution. There is no concept of installing global utilities in NuGet.
So because you will use NPM in every single project, I think you need to learn the commands.
Furthermore, you do need to learn TypeScript. OK, you don’t have to learn TypeScript, but you really should… at least in my opinion. It's sort of like back in the day when every code sample Microsoft was shipping early on was C# and all the VB developers were constantly asking for VB.NET samples.
Really? Yup! Here’s why: first, the only reason you need Node.js is that all the other tools (NPM, Gulp, Yeoman, Webpack and the TypeScript compiler) are all built on Node.js. Therefore you need it to run these tools. But once installed, you don’t care about it anymore. You don’t write a Node.js program at any time… you just install it and forget about it.
Gulp, as you see, is used to run tasks like building or deploying code. While you can learn to build your own custom tasks, you do not need to. Microsoft has given you all the tasks you need for most SharePoint Framework development so you just need to know how to type the command to get it going. For instance, to start the local workbench environment, just type gulp serve.
Yeoman is very much like Gulp in this sense. You need it to scaffold up your projects, but you do not need to know how to write your own generators. Instead, you just need to know how to run the generator which can be boiled down to three keystrokes at the command prompt: yo<enter>.
As for Webpack, I’m going to explain more detail how this is used, but this is by far the easiest to ignore. Why? Because first, you never even install it! Microsoft’s default setup is to include a copy of Webpack in every single project scaffolding. Now, I’m not saying that’s a good practice… I’m not sure it is, but I'm not saying it. ;) Webpack needs a configuration file which is created by Microsoft’s build process in memory. Therefore you never see it, you never call it, and Microsoft does all the configuration of it for you.
Hopefully, this has cleared up some things that were a bit intimidating or gave you pause. In future installments, I’ll look at each of these things in a bit more detail and explain why you need them, how you install them and how they work. We will start tomorrow with Node.js & NPM. See you then!