sp-dev-fx-webparts: the SharePoint Framework sample library

A pattern catalogue, not a library you take a dependency on

The README is explicit that this is community samples demonstrating usage patterns for SharePoint Framework client-side web parts, and the repository description calls them samples and tutorial materials too. That framing decides how to read the code. Nothing here is published to npm for you to install; you clone the repository, change into a folder and use the source as a starting point.

The README describes what a client-side web part is in one useful paragraph: a control that appears inside a SharePoint page but runs locally in the browser, built with modern script development tools and the SharePoint workbench, deployable to classic web part pages in Office 365 tenants. The same paragraph names AngularJS and React as companion frameworks, and points at Office UI Fabric React components as a way to match the look of Office 365.

That last point is the reason the catalogue is wide. The sample folders in the repository cover plain JavaScript and TypeScript as well as Angular, React, AngularJS, Knockout, Handlebars, jQuery and even a Bootstrap slider, so you can see how the same platform contract is satisfied from several very different rendering models. Names such as `angular-todo`, `js-employee-spotlight`, `jquery-photopile` and `angular-migration` tell you the intended lesson without opening the folder.

Teams tabs and personal apps in the description, web parts in the README

The repository description advertises SharePoint Framework web part, Teams tab, personal app and app page samples. The README never mentions Teams tabs or personal apps. It describes client-side web parts and deployment to classic web part pages, and nothing further. Both statements are sitting in front of you at the same time, so neither one should be quietly rewritten into the other.

The README's account is the narrower and more carefully argued one, since it explains what a web part is and how it is built and deployed. The description field is a one-line summary that tends to lag or run ahead of the documentation. Both may still be true at once, because the same repository can hold Teams tab and personal app samples that the README simply does not enumerate.

The check that settles it costs one listing of the tree. Open the samples directory and look for folders whose names reference tabs, personal or app pages rather than a framework. If the sample folders are all web part work, treat the description as marketing breadth and use the README as the description of what actually builds. If folders covering those other extension types exist, the README is simply under-documented, and the folder names tell you which shape to start from.

Cloning the repository and switching to the sample you want

The entry sequence is four commands and the README is careful about the middle step, because skipping it is the most common way to fail.

git clone https://github.com/pnp/sp-dev-fx-webparts.git

cd sp-dev-fx-webparts

Then the two-step move into a sample, where the second command is a placeholder you replace with a real folder name:

cd samples
cd sample-folder-name

That navigation detail matters more than it looks. A sample folder is a self-contained solution with its own package.json, so running install at the repository root would resolve the wrong dependency graph entirely. The README also says the repository root carries a package-lock.json, which belongs to the samples collection rather than to any single web part.

Node version pinning is the step people skip

Before installing anything the README asks you to get the Node version right, and it gives three ways to determine it. Consult the README.md inside the sample folder, which states a Node version recommendation, or consult the SPFx Compatibility Matrix at aka.ms/spfx-matrix for the Node versions supported by the SPFx version that sample uses.

Some sample folders also ship an `.nvmrc` file, which the README describes as a version specifier usable with a Node version manager such as nvm or nvs. With one present, the switch is a single command run inside that folder:

nvm use

nvs use

This is the most fragile part of the whole workflow, for a reason specific to a catalogue like this. The samples were written against a range of SPFx versions, and SPFx pins the Node major version it supports. A sample with no `.nvmrc` therefore has no automatic answer, and the folder README is the only place the required version is recorded. If a build fails immediately after install, check that file before touching anything else.

Install, then serve the workbench

With the correct Node active, the remaining two commands are the whole build. Install pulls the npm packages and dependencies for that specific client-side project:

npm install

Then the preview step, which runs the local server against SharePoint Workbench:

gulp serve

The workbench is described in the README as a development test surface, which is the honest framing for what it is: a local page where the sample renders before it is deployed to a tenant. Deployment itself is where this repository gets thin. The README states that client-side web parts can be deployed to classic web part pages in Office 365 tenants, but it does not document the packaging and upload steps, and no deployment command appears in it.

One more gap worth naming: `gulp serve` assumes a gulp binary is resolvable, and the README does not tell you to install one globally. If the command fails immediately, a missing global gulp is the first thing to check, since the samples themselves carry the gulp configuration in their own folders.

Active pushes, releases that stopped in 2021

The activity signals here point in different directions and both are worth knowing. The last push to the main branch was on 2026-09-28, and the repository is not archived. The releases tell a different story: the most recent is 1.1.0 from 2021-04-09, and the two before it are 265958 from 2020-12-31 and 249729 from 2020-12-12.

The release list is best read as release notes for the collection at a moment, not as a version line that tracks the code. Two of those three tags are bare numbers rather than version strings, which is the signature of a tag pushed to mark a documentation change or a sample merge. So the repository is receiving commits while the published release record has been static for years.

Practically, that means do not treat 1.1.0 as the version of the samples you are reading. Judge each folder by its own README and its own dependency versions, which is the only signal the repository maintains per sample. The MIT licence field matches a LICENSE file at the root, and the tree also carries SECURITY.md, SUPPORT.md, CONTRIBUTING.md and CODE_OF_CONDUCT.md, so the governance documents are present even though the releases are not.

Getting an answer: two issue trackers, deliberately

The README splits support routing in a way that saves time. A general question or a challenge with SPFx as a whole belongs on the sp-dev-docs repository issue list, while an issue on one specific web part or sample belongs on the issue list here. Sending everything to one queue slows both down.

The three documentation links the README offers all point at Microsoft Learn rather than at material kept in this repository: the overview of the SharePoint Framework, the page on development tools and libraries, and the getting started guide. That is the honest boundary of the project. The repository holds patterns, and Microsoft Learn holds the framework documentation.

Contributions are welcome to the samples folder, with one condition the README states outright: if your sample uses third party libraries, that library's licence has to permit redistribution as part of the sample. Samples are attributed as coming from the feature teams, the SharePoint PnP core team or the community, each in its own solution, and the project describes itself as an open source community project whose contributors are volunteers.

Editorial conclusion

This repository is worth your time if you want a working SPFx pattern to copy rather than a framework to depend on: the sample folders are self-contained, the build path is three commands, and each one names the Node version it expects. It is the wrong place to look for a maintained UI component library, for the tooling that scaffolds a new solution, or for anything newer than what its last release suggests. To use one, clone the repository, run nvm use inside the sample folder that ships an .nvmrc, then npm install and gulp serve, and confirm the Node version against the SPFx compatibility matrix before you debug anything else.

Frequently asked questions

Official sources

1. License: MIT
2. pnp/sp-dev-fx-webparts on GitHub
3. Project website
4. README
5. Releases