What is Required Toolchain for SharePoint Framework




Suggested Articles


What is SharePoint Framework (SPFx)

Future prospects of SharePoint Framework (SPFx)

Required tools and libraries for SharePoint Framework (SPFx) development

Setup Office 365 tenant for SharePoint Framework development

Setup SharePoint Framework client side web part development environment

Build SharePoint client side web part using SharePoint Framework (SPFx) – I

Build SharePoint client side web part using SharePoint Framework (SPFx) – II

Build SharePoint client side web part using SharePoint Framework (SPFx) – III

How to Debug SharePoint Framework Solutions in Visual Studio Code

What is the Developers Point of View on SharePoint Framework


This SharePoint Freamework toolchain represents a set of building tools, libraries and framework packages which help building and deploying client side projects. Toolchain helps to client side components to be developed and tested on environment which has SharePoint Workbench.

You can also use toolchain for code compilation, packaging the client-side projects into SharePoint app package.




SharePoint Framework uses npm to manage different modules in the project. npm is one of the most preferred package manager for JavaScript client-side development. npm includes one or more JavaScript code files which are called as modules. When you install npm it installs its modules and dependency packages.

SharePoint Framework not only uses npm packages but also uses its dependencies and publish own packages to npm registry.



SharePoint Framework packages

SharePoint Framework contains several npm packages which work together for developers. List of those packages are provided below:

  • @microsoft/generator-sharepoint

It is a Yeoman plug-in which is used to setup a client side project for SharePoint Framework. It automatically adds all defaults, best practices and required packages.

  • @microsoft/sp-client-base

It defines core libraries of client side application required for SharePoint Framework.

  • @microsoft/sp-webpart-workbench

This is local environment for testing and debugging client side application.

  • @microsoft/sp-module-loader

It is responsible for versioning and loading client side components, web-parts and other assets. It is built upon SystemJS and WebPack standards and is the first module of SharePoint Framework to load on page.

  • @microsoft/sp-module-interfaces

It defines various shared interfaces used by other modules of SharePoint Framework.

  • @microsoft/sp-lodash-subset

It provides custom bundle of lodash for use with SharePoint Framework’s module loader. It only includes a subset of most essential functions.

  • @microsoft/sp-tslint-rules

It defines custom tslint rules for usage with SharePoint client-side projects.

  • @microsoft/office-ui-fabric-react-bundle

It provides a custom bundle of office-ui-fabric-react that is optimized for use with the SharePoint Framework’s module loader.



Common building tools packages

SharePoint also uses few building tools which are used to perform required building tasks for SharePoint Framework like compiling Typescript to JavaScript and SCSS to CSS.

  1. @microsoft/sp-build-core-tasks
  2. @microsoft/sp-build-web
  3. @microsoft/gulp-core-build
  4. @microsoft/loader-cased-file
  5. @microsoft/loader-load-themed-styles
  6. @microsoft/loader-raw-script
  7. @microsoft/loader-set-webpack-public


Package installation

The SharePoint Generator installs required npm packages in the project. These packages can be installed in two ways either locally or globally. In case of web part projects, web part code depends on various SharePoint and common build packages therefore it requires these packages to be installed locally.

When we install any package, it is provisioned in node_modules folder in project structure. This folder contains the packages along with all of the dependencies. SharePoint Framework packages are located under node_module\@microsoft folder. @microsoft denotes that these npm packages are published by Microsoft.

Every time you create new project using generator, generator installs SharePoint framework packages and its dependencies. This way, npm makes developers life easy by managing web part projects without affecting other projects in local development environment.


The package.json file is kept in client side project. It contains a list of dependencies the projects depends on. Each dependency may also have dependencies. In this file, we can provide dependencies based on criteria like runtime dependencies and build dependencies for the package. You can see two properties as “dependencies” and “devDependencies”. The “devDependencies” property informs about dependencies to be required for build. Let us see an example below.


  “name”: “helloword-webpart”,

  “version”: “0.0.1”,

  “private”: true,

  “engines”: {

    “node”: “>=0.10.0”


  “dependencies”: {

    “@microsoft/sp-client-base”: “~1.0.0”,

    “@microsoft/sp-core-library”: “~1.0.0”,

    “@microsoft/sp-webpart-base”: “~1.0.0”,

    “@types/webpack-env”: “>=1.12.1 <1.14.0”


  “devDependencies”: {

    “@microsoft/sp-build-web”: “~1.0.0”,

    “@microsoft/sp-module-interfaces”: “~1.0.0”,

    “@microsoft/sp-webpart-workbench”: “~1.0.0”,

    “gulp”: “~3.9.1”,

    “@types/chai”: “>=3.4.34 <3.6.0”,

    “@types/mocha”: “>=2.2.33 <2.6.0”


  “scripts”: {

    “build”: “gulp bundle”,

    “clean”: “gulp clean”,

    “test”: “gulp test”



However there is a lot of packages installed on development machine, but these are for implementation, building, compiling, bundling and packaging. Final minified version of web part which is deployed on CDN or SharePoint doesn’t include any of these packages.



Working with Source Control system

In the preferred case, we don’t want to check-in all dependencies available in node_modules folder into source control. It can be done if we exclude node_modules folder from list of files to ignore during check-ins.

If you are using “git” as your source control system, Yeoman scaffolded web part project contains a file with extension .gitignore. This file helps to ignore node_modules folder and items if you need.

Now, what will happen, if other team member downloads code from source control first time? How will that machine get dependencies required for project? The answer is very simple. You have run following command.

npm i

npm will scan the package.json file and install the required dependencies.



SharePoint Framework build tasks

SharePoint Framework uses gulp as its Task Runner to perform following processes:

  1. Bundle and minify JavaScript and CSS files.
  2. Run tools to call the bundling and minification tasks before each build.
  3. Compile LESS or SASS files to CSS.
  4. Compile TypeScript files to JavaScript.

The toolchain has following tasks which are defined in @microsoft/sp-build-core-tasks package.

  1. build – Builds the client-side solution project
  2. bundle – Bundles the client-side solution project entry point and all its dependencies into a single JavaScript file.
  3. serve – Serves the client-side solution project and assets from the local machine.
  4. nuke – Cleans the client-side solution project’s build artifacts from the previous build and from the build target directories (lib and dist)
  5. test – Runs unit tests, if available, for the client-side solution project.
  6. package-solution – Packages the client-side solution into a SharePoint package.
  7. deploy-azure-store – Deploys client-side solution project assets to Azure Storage.

However, you can also create your own gulp task. To run these tasks, append the task name with gulp command for example.

gulp <task-name>

e.g. gulp serve

You cannot run multiple tasks at a time in single command. The command “serve” runs different tasks targeted as BUILD mode and launches SharePoint Workbench. But if “ship” parameter is specified, command targets to SHIP mode.



Usually, when your web part project is ready to ship or deploy in a production server, you will target SHIP. For other scenarios like testing and debugging you would target BUILD. The SHIP target also ensures that the minified version of the web part bundle is built.

To target SHIP mode, you append the task with –ship:

gulp –ship

In DEBUG mode, the build tasks copy all of the web part assets, including the web part bundle, into the “dist” folder.

In SHIP mode, the build tasks copy all of the web part assets, including the web part bundle, into the “temp\deploy” folder.



What’s next

I have covered SharePoint Framework Toolchain and have also described that we can create custom gulp task by our self.

In the next article, we’ll go through building it.


Thank you for reading…

Please like, share and subscribe!





THREE QUERIES offers easy access to information about SharePoint and associated technologies, project management, agile and scrum methodologies that helps developers, administrators, architects, technical managers, business analysts and end users. It has grown from there. We provide an important knowledge base for those involved in managing, architecture and developing software projects of all kinds. With weekly/daily exclusive updates, we keep you in touch with the latest business, management, technology thinking.

WE ARE CONNECTED ~ Follow us on social media to get regular updates and opinion on what's happening in the world of SharePoint, front-end, back end web technologies and project management. If you like this article, please share it and follow us at Facebook, Twitter, Instagram and LinkedIn

About Satyendra Mishra

Microsoft certified, motivated, energetic and accomplished SharePoint Consultant and Architect with 13+ years of work experience in Management, Architecture, Analytics, Development and Maintenance. He has been fortunate to be a part of over 20+ Web/Mobile/Software SharePoint and .Net projects delivery with various companies across different industry sectors. This has provided him a valuable insight and experience especially in successful implementation of technology solutions. Having very strong System Architecture, Technological, Management & Analytical Skills, Knowledge of Office 365, SharePoint, .Net, JavaScript, React, Angular, Azure, SQL. In 2016, he decided to start sharing the knowledge back to society in the form for content writing and blogging.
View all posts by Satyendra Mishra →

Leave a Reply

Your email address will not be published. Required fields are marked *