sp-dev-fx-extensions: the SharePoint Framework extension sample library

A catalogue of extension patterns, not a framework

The repository's stated purpose is narrow and honest: it contains the samples that demonstrate different usage patterns for the SharePoint Framework extensions. That makes it a catalogue, and its value to an engineer is as reference examples rather than as a dependency.

The surrounding definition in the README is worth keeping in view, because it explains what the samples actually are. SharePoint extensions are controls that appear inside a SharePoint page but run locally in the browser, and they are the building blocks of pages on a SharePoint site. You build them with modern script development tools and deploy them to modern pages in Office 365 tenants. Alongside plain JavaScript projects, extensions can be built with common scripting frameworks such as AngularJS and React, and the README points at using React together with Fluent UI components to build experiences from the same components Office 365 uses natively.

Two constraints follow from that framing. First, the samples are demonstrations of patterns, so a working sample is a starting point you adapt, not a module you import. Second, because these are browser-side controls, everything they touch runs in the tenant of whoever opens the page, which is a constraint the sample code has to respect.

The samples folder shows one directory per extension type

The top level of the repository holds samples/, templates/ and tutorials/, alongside community files such as CODE_OF_CONDUCT.md, CONTRIBUTING.md, SECURITY.md and SUPPORT.md. The samples directory is where the actual variety lives, and the listing of sample folders is a compact map of the extension surface.

The naming is systematic. Entries beginning js-application cover application customizer patterns, and the folder names name the behaviour rather than the feature area: js-application-alert-message, js-application-appinsights, js-application-appinsights-advanced, js-application-dynamically-importing-styles, js-application-graph-client, js-application-gtm-injector, js-application-header-toggler, js-application-intranet-searchbox, js-application-layout-customizer, js-application-listdrivenplaceholders, js-application-microsoft-clarity, js-application-redirect and js-application-run-once. Entries beginning js-field cover field customizers, with js-field-animated-progress and js-field-conditionalformatting listed. Entries beginning js-command cover list command extensions, and that group is the largest: clone, convert-to-pdf, copy-classic-link, hide-commands, item-permissions, lock-item and selecteditems-export.

The two jquery-prefixed folders, jquery-application-toastr and jquery-field-itemorder, show that the older AngularJS and jQuery style is still represented alongside the plain JavaScript entries. For a reader trying to work out which extension type to reach for, this directory listing is more informative than any documentation page, because it shows what other people have actually built.

Cloning and building a single sample

The samples are not published to a package registry. To use them you clone the repository and build the sample you need, and the README walks through it as a short sequence of console commands. First the clone:

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

Then you move into the cloned folder, which carries the same name as the repository:

cd sp-dev-fx-extensions

Samples and tutorials live in separate top-level directories, so you navigate into the one you want. For a sample you replace sample-folder-name with the name of the sample you want to access:

cd samples
cd sample-folder-name

For the tutorial files the path is simply:

cd tutorials

The next step installs the dependencies for that project, which the README explains as the required npm packages and dependencies to build and run the client-side project:

npm install

This per-sample install is worth noticing. Each sample is contained in its own solution, so the dependency graph is per folder rather than one workspace install for the whole repository, and you only pay for the packages the sample you picked actually declares.

gulp serve hosts the extension locally for preview

Once the packages are installed, the documented way to see the extension is to start nodejs so it can host the extension and preview it in SharePoint Online pages:

gulp serve

The value of that step is that it removes the deployment loop from the edit-and-check cycle. You run a local server, the extension is served into a SharePoint Online page, and you can see the behaviour without packaging and uploading an app through the tenant. For a customizer pattern that manipulates field rendering or adds a list command, seeing the real page react is faster than reasoning about the code.

What the README does not tell you is worth flagging too. It does not document which SharePoint Framework version each sample targets, what the gulp tasks do beyond serve, or how the local server authenticates against your tenant. There is no compatibility table in this repository, so the practical assumption is that a sample was written against the framework generation current when it was written, and that a mismatch shows up as a build or a runtime error rather than as a warning you can read off the page.

Releases stopped in 2020 while commits kept landing

The release history and the commit history tell different stories, and the difference matters when you decide how much to trust a sample.

The most recent published releases are three dated 2020-12-17, two of them titled SharePoint Framework Extensions Samples & Tutorial Materials and one titled Google Analytics Application Customizer. That is the entire recent release set, and it is more than five years old relative to the repository's last push, which was on 2026-10-18. The repository is not archived, so this is not a dead project. It is a project whose published release artefacts stopped while the source kept moving, which is what you would expect from a sample collection that is updated in place rather than versioned as a deliverable.

Practically, that means there is no artifact to pin. You clone the branch you want and read the code, and if you need reproducibility you commit the sample into your own repository, which is also the only way to satisfy a licensing review of the third-party libraries the samples pull in. Nothing in the release list gives you a supported version of the framework or a matching set of samples.

Third-party libraries in samples come with a licence caveat

The README asks something of contributors that is easy to miss and worth repeating to anyone copying from the repository. It welcomes community contributions to the samples folder for demonstrating different use cases with SharePoint Framework, but adds the condition that if you use third-party libraries, you should make sure the library licence allows distribution of it as part of your sample.

That is a distribution warning sitting on top of a repository whose own licence is MIT. The MIT terms cover the sample code in this repository. They do not automatically cover the analytics, tracking or UI libraries a given sample imports, and those carry their own terms. The practical failure mode is concrete: a sample that includes a client-side library with attribution or copyleft requirements can pull those requirements into a product you ship.

So when you lift a sample into a commercial solution, the licence check is not a formality applied to the repository. It applies to the dependencies declared in that sample's package.json, one folder at a time, and a sample being under MIT says nothing about the rest of its tree.

Where to file a question, and what the community calls add

The README splits issue routing explicitly, and the split is a shortcut to a faster answer. General questions or challenges with SPFx go to the sp-dev-docs repository issue list. An issue on a specific extension or sample goes to the issue list in this repository. Nothing in the first list is a good place to report a broken sample, and nothing in the second is a good place to ask how the framework works.

Contributions are handled on community terms. The README states that the repository's contributors are all community members who volunteered their time to share code samples, that the work is done as an open source community project, and that each sample is contained in its own solution. The samples are described as coming directly from the feature teams, the SharePoint PnP core team, or the wider community, and pull requests are routed through the contribution guidance in the repository root.

The repository also points at weekly community calls covering Copilot, Microsoft 365 and Power Platform topics, with a public call schedule and recurring invites. For a sample library maintained by volunteers, that call is where the context lives, and it is a better place to ask about the direction of a sample than a GitHub issue on a six-year-old release.

Editorial conclusion

Use sp-dev-fx-extensions when you need a working reference for a specific SharePoint Framework extension pattern, such as a field customizer, an application customizer or a list command, and when a copied sample that you own is acceptable. Do not treat it as a maintained distribution of the framework itself, because the published releases date from 2020-12-17 and carry no version compatibility statement for current tenants, and do not copy a sample into production without checking the dependency licences as the README itself requires. Before you commit, run npm install and gulp serve inside the sample folder you intend to use, check the versions pinned in that sample's package.json against your tenant, and confirm your question belongs in this repository's issue list rather than the sp-dev-docs issue list the README points general SPFx questions to.

Frequently asked questions

Official sources

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