SPFx Development Toolchain Approach (Day 4 / 10)

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, I compared the development and deployment story for customizations created using the SharePoint Framework to those using a more traditional SharePoint approach.

Today, I will provide an overview of the SharePoint Framework development toolchain.

But first, consider how does this new SharePoint Framework style of development compare to the traditional SharePoint development style?

The things you will build for the SharePoint Framework to deploy into your SharePoint deployments are just web assets. What you build will be used to implement a client-side experience.

But like solutions and add-ins you need a way to get these into your SharePoint environment. This is done using… SharePoint packages (*.sppkg). A SharePoint package which is just a special ZIP file. The package contains all the files needed for your customization as well as a few generated JSON and XML files SharePoint needs.

You need tools to create these packages. 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. As you will see in this series, this yields a lot of flexibility and choice which is great as it opens SharePoint development up to many more developers.

There is a downside though… at the present time, we do not have tools for Visual Studio. That might be frustrating to those of you who are only familiar with using Visual Studio as your SharePoint development environment.

The first thing you will need is a SharePoint developer tenant. This is a tenant in SharePoint online in office 365. You will absolutely want to test your customizations here as it’s a real SharePoint environment. This environment also has a copy of the SharePoint workbench that you can use to test your web parts out as well. The workbench is a locally hosted page that can host your SharePoint client-side web parts. Using this page you can develop and test locally, all without a full SharePoint deployment!

Now let’s look at the different tools you will need, but in doing so, let’s compare them to what you are used to using if you are coming from the traditional SharePoint or .NET development world.


The traditional Microsoft way of doing development is building on the .NET Framework. This is the runtime that knows how to run the programs.

Node.js addresses this need. A lot of the tools in the modern web development world are built on top of Node.js.


When building .NET applications, we use a tool called NuGet to acquire prebuilt packages for use within our application.

In the Node world, we use a tool called NPM that does the same thing. We will use this to get packages our customizations need like Angular, jQuery or other useful libraries.


Visual Studio is Microsoft’s integrated development environment. When we want to create a new project, we use Visual Studio’s project templates to create the file & folder scaffolding for the project.

With the SharePoint Framework, you can use any editor you want. But to get the folder & file scaffolding created for the project we use a tool called Yeoman. You can install different project generators for Yeoman. Microsoft provides one for SharePoint client-side web parts that we will use as the starting point for our new project.


Now, you know when you build a project in Visual Studio, some process kicks off to compile the project, maybe it manually starts up another process with your app in it and attaches a debugger? That’s not Visual Studio doing that, that’s Visual Studio calling MSBuild. Someone created tasks for MSBuild using an XML syntax 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.

The tool Gulp does the same thing. It allows you to write tasks using JavaScript and then tell Gulp to run those tasks for you.


This comparison is not exact, but you’ll get the point. With a traditional SharePoint project, you compile the project files into an executable or a DLL.

In the JavaScript world, we have a similar process where we want to merge multiple files into a single bigger file for performance & manageability. The tool Microsoft selected for the SharePoint Framework is Webpack.

A lot of new terms huh? Intimidated? Don’t be… it’s actually pretty simple, everything is free and does not require some big install. With a typical broadband connection, you can be up and running in 10 minutes or less.

Now, before I go into each of these things in depth, in tomorrow’s installment I will simplify things; let’s identify just the things you need to know vs the things you can install and move on. Until tomorrow!