With the introduction of SharePoint Framework (SPFx), SharePoint development model now supports client-side development. Developers get a highly robust and extensible client-side framework to build and deploy SharePoint customizations. On top of that, SharePoint as a product is also adopting SPFx as its core model to build new capabilities and features into the platform.
Today, SPFx is available as a developer preview in Office 365. It will also be available to SharePoint 2016 on-premises releases, targeting 2017. However, as new features and capabilities gets released, it is unfortunate to not have those features and capabilities available to all versions/releases of that product (due to various technical and product management cost/troubles/issues).
So, if you are using earlier versions of SharePoint, you might be wondering how you can make use of this client-side framework to build and deploy client-side customizations.
Well, yes and no.
One of the advantages of being client-side driven is that you can adopt similar development model and patterns to earlier versions of SharePoint as well. For example, with app script web part pattern, you are able to build and deploy a web part, both in Office 365 and on-premises, built entirely using client-side scripting. Building customizations using client-side web stack isn’t new to SharePoint developers. What’s new with SPFx is the client-side framework that allows developers to build customizations in a more consistent and supported manner by providing the key extension points in SharePoint.
As you might have guessed, you can use this build toolchain in any web project. That is exactly where I am going.
The SPFx toolchain uses a set of open source npm packages to achieve this and thus opening the options to use these in any web project, including the client-side customizations you are building with SharePoint.
Just think about this a moment. The build pipeline is open, extensible and can be used in any web project, not just SPFx projects.
SharePoint PnP published a post on this topic — Using modern web stack with SharePoint on-premises deployments — which I would recommend everyone interested in this topic to read and watch the webcast as well as it shows how to use this toolchain to build a generic react web app.
The generic react web app used in the SharePoint PnP webcast is available here for you to play with.
First step is to get to know these toolchain packages. Below are the list of those common build toolchain packages. A big advantage I see is that these packages are divided into different small npm packages (rather than one big package) and helps to pick and choose what you want.
- @microsoft/gulp-core-build — The core gulp build tasks for building TypeScript, HTML, less, and other build formats. This package depends on several other npm packages that contains other tasks.
GitHub project: https://github.com/microsoft/gulp-core-build
- @microsoft/gulp-core-build-typescript — Contains gulp-core-build subtasks for compiling and linting TypeScript code.
GitHub project: https://github.com/microsoft/gulp-core-build-typescript
- @microsoft/gulp-core-build-sass — A gulp-core-build subtask which processes SCSS files using SASS, runs them through postcss, and produces commonjs/amd modules which are injected using the
GitHub project: https://github.com/microsoft/gulp-core-build-sass
- @microsoft/gulp-core-build-webpack — A gulp-core-build subtask which introduces the ability to bundle various source files into a set of bundles, using webpack.
GitHub project: https://github.com/microsoft/gulp-core-build-webpack
- @microsoft/gulp-core-build-serve — A gulp-core-build subtask for testing/serving web content on the localhost, and live reloading it when things change.
GitHub project: https://github.com/microsoft/gulp-core-build-serve
- @microsoft/gulp-core-build-karma — A gulp-core-build subtask for running unit tests using karma/phantomjs/mocha/chai. This setup allows you to run browser based testing.
GitHub project: https://github.com/microsoft/gulp-core-build-karma
- @microsoft/gulp-core-build-mocha — A gulp-core-build subtask for running unit tests and creating coverage reports using mocha/chai. This setup is useful for unit testing build tools, as it runs in the node process rather than in a browser.
GitHub project: https://github.com/microsoft/gulp-core-build-mocha
- @microsoft/loader-load-themed-styles — A loader that wraps the loading of CSS in script equivalent to
require('load-themed-styles').loadStyles( /* css text */ ). It is designed to be a replacement for style-loader.
GitHub project: https://github.com/microsoft/loader-load-themed-styles
- @microsoft/loader-raw-script — A loader that loads a script file’s contents directly in a webpack bundle using an
GitHub project: https://github.com/microsoft/loader-raw-script
- @microsoft/loader-set-webpack-public-path — A loader that sets the webpack_public_path variable to a value specified in the arguments, optionally appended to the SystemJs baseURL property.
GitHub project: https://github.com/microsoft/loader-set-webpack-public-path
This should give you a good picture of the web stack used and how similar they are when you compare building SPFx client-side solutions.
In the next set of posts, we will go through in building a web project using these build tools.