# sp-dev-solutions: community solution samples for SharePoint > The pnp/sp-dev-solutions repository holds end-to-end SharePoint solution samples contributed by the Microsoft 365 Platform Community team and the wider community, each with its own folder, its own readme and its own build. The set covers change requests, contacts, inventory checkout, multilingual pages, the Pages API and a modern search experience. **pnp/sp-dev-solutions** — Repository for SharePoint development reusable solutions - Repository: https://github.com/pnp/sp-dev-solutions - Stars: 524 · Forks: 434 - Language: TypeScript - License: NOASSERTION - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/pnp-sp-dev-solutions ## What the repository actually is The pnp/sp-dev-solutions repository is described in its own front matter as a repository for SharePoint development reusable solutions, and the readme welcomes you to the Microsoft 365 Platform Community Solutions for SharePoint. The framing that matters is that these are samples and templates to use as foundations and patterns of solutions related to SharePoint technologies. The readme goes further and says the samples are end-to-end solutions containing all of the components needed to fulfil productivity needs of users and teams, and that for developers these are extended examples containing modules and patterns you may find useful to re-use in your own solutions. So the unit of value is the whole application, not a component. Each solution is a working scenario rather than a library, and the intent is that you take it apart and reuse the parts that fit your problem. The status is stated without hedging. These web parts are currently in preview, and undergoing further updates to improve quality and add capabilities, based on your feedback. That is an important thing to know before you build on one, because preview means the shape of the code and the available capabilities may both change. The readme also makes the contribution model explicit. It welcomes reported issues, pull requests and new solution samples, with issues and feature requests going through the GitHub issues list and pull requests for bug fixes. For new solutions, the readme says you will want to review the solutions standards criteria for inclusion, and points at the contribution guidance in the .github directory. That is a different model from most open source projects, where anything that works gets merged. A standards criteria implies a review board deciding whether a sample belongs, which is reasonable for a repository that presents itself as a curated set of Microsoft-recommended patterns rather than a dumping ground. The licence is recorded as a custom one that GitHub cannot classify, and the repository carries a LICENSE file and a ThirdPartyNotices.txt, which is the usual pairing for a set of samples that pull in third party code. ## The solution catalogue The table of solutions is the substance of the repository, and each entry describes a complete productivity scenario rather than a technical component. ChangeRequests manages and closes change requests opened by users, which is the kind of workflow that a company with a change advisory board would otherwise build from scratch. Column Formatter is an easy editor for modern list view column formatting, which is the SharePoint feature where you define how a column renders without writing code. ContactManagement organises and manages contacts and organisations, which again sounds simple until you need it to work with the platform's own model rather than a bolted-on database. LinksAndHandlebarsTemplate is the one with the longest description, and it is the most technically interesting. Different kinds of visuals for hosting sets of links on a page, including with custom Handlebars Templates. Handlebars templating in a SharePoint page lets a set of link items render through a template rather than through the fixed field editor, which is the difference between a links list and a designed call-to-action panel. Multilingual Pages creates, manages and consumes multilingual pages based on the user's preferred language, which on SharePoint means dealing with the fact that the platform's language model is per-site while the user's preference is per-person. Pages API is a solution to using the Pages API to get, create, update and delete SharePoint Pages, which is the REST surface for the newer Pages rather than the old wiki pages. InventoryCheckOut manages a list of items in an inventory and lets users check out and reserve items, which is the checkout pattern for physical assets. Site Designs Studio enables management of Site Designs and Site Scripts directly in the browser, which is a tooling solution for the people who apply the designs rather than build them. TimeAway provides a simple out-of-office tracker for members of your team. And the modern search work has two entries rather than one, which is worth noting because the split tells you the structure of the solution. ModernSearch is a user-friendly search experience in the modern SharePoint interface, and ModernSearchRenderers holds custom renderers for that solution. Separating the renderers into their own sample means you can adopt a different search experience and keep the rendering layer. ## How you build and run one The readme gives the workflow for the solutions in a form that assumes you will be doing this repeatedly, one solution at a time. First you clone the repository: ```bash git clone https://github.com/pnp/sp-dev-solutions.git ``` Then you navigate into the cloned repository folder, which should be the same as the repository name: ```bash cd sp-dev-solutions ``` Then you change into the solution folder you want, replacing solution-folder-name with the name of the solution you want to access: ```bash cd solution-folder-name ``` Then you install the npm packages, which installs the required npm packages and dependencies to build and run the client-side project: ```bash npm install ``` And once the packages are installed, you run the following command to preview your web parts in SharePoint Workbench: ```bash gulp serve ``` Two things in that sequence are worth pausing on. The first is that each solution is an independent npm project with its own dependencies, so the repository is not a monorepo with a shared install. You move into the folder and run npm install there, which means a dozen solutions means a dozen installs, and a clean checkout of the whole tree is a lot of node_modules. The second is the SharePoint Workbench. The gulp serve command starts the local development server and opens the Workbench, which is the hosted test harness inside a SharePoint site where the web part can be added and exercised against real list data. That is a meaningful difference from a standalone React app: these solutions are not self-contained, they run inside a SharePoint tenant and talk to lists, columns and the Pages API. The gulp task is the older build tool for SharePoint Framework work, and it is worth noting that the readme still uses it rather than a newer bundler story. Combined with the preview status, that tells you these samples are built against a particular generation of the framework. The readme links an overview of the SharePoint Framework as the additional resource, which is the right place to start if you do not already know how web parts are packaged and hosted. ## Who contributes, and how the repository is licensed The contributions section explains the provenance of the samples, and it is unusually clear about the mixture. These solutions are direct from the feature teams, from the Microsoft 365 Platform Community core team, or shared by the community. The project's contributors include Microsoft and community contributors, listed in a Contributors.md file. And the work is done as an open source community project. That distinction matters for anyone adopting a sample. A sample written by the feature team that owns the product area and a sample shared by a community member are likely to differ in how closely they track current platform behaviour, and the repository does not claim they are equivalent. The contribution route has a specific requirement for new work. Please have a look on the Contribution Guidance before submitting your pull requests, so that you can get your contribution processed as fast as possible. For new solutions specifically, the readme points at the solutions standards criteria for inclusion. So there are two gates. The general contribution guidance applies to everything, and there is an additional criterion for a new solution sample, which suggests that adding an existing pattern to the collection is easier than adding a new pattern. The disclaimer is the standard one and it is worth reading anyway. The code is provided as is, without warranty of any kind, either express or implied, including any implied warranties of fitness for a particular purpose, merchantability or non-infringement. For sample code that people copy into production, that disclaimer is the boundary of what Microsoft is taking responsibility for, and it applies to every solution in the collection. The repository structure is simple. There is a solutions/ directory holding the individual samples, the .github directory with the contribution guidance and the issue templates, a Contributors.md, a ThirdPartyNotices.txt for the licences of vendored code, the LICENSE file and the README itself. One oddity in the release history is worth mentioning. The recent releases are numbered builds rather than versions, with three entries numbered 248908, 249643 and 249644 all dated December 2020. Those look like internal build identifiers used by the release pipeline rather than a semantic version series, and the last push was on 2026-09-28. So the repository is being worked on, but the tag history does not reflect that. ## What the platform context means for reuse A sample repository only earns its place if the code it contains survives contact with a real project, and in the SharePoint case the platform context is what decides that. The web parts in this repository are not standalone applications. They run inside a SharePoint tenant, they read and write list items through the platform's own model, and some of them reach the Pages API rather than the older pages surface. That has direct consequences for anyone planning to reuse them. The configuration is in the tenant rather than in a config file, the permission model is the SharePoint permission model, and a solution that assumes a particular list or a particular site column layout will need that structure recreated wherever you deploy it. The end-to-end framing in the readme is the right way to think about this. A solution that includes its list definitions, its views and its web part is a complete scenario you can deploy and look at, which tells you far more about how the pieces fit together than a partial sample would. The cost is that it is heavier to adopt piecemeal, and the readme's own advice to developers is that you will find some modules and patterns useful to reuse rather than the whole thing. The LinksAndHandlebarsTemplate sample shows the pattern in miniature. The value of Handlebars templating in a SharePoint page is that a set of link items can be rendered through a template, so the presentation lives in the template rather than in the fixed field rendering. Reusing that idea means bringing the template with you and pointing it at your own link list, which is a much smaller adaptation than reusing a whole application. The Site Designs Studio sample points at the other direction, where the reusable artefact is a configuration rather than code. It is for the people who apply site designs and scripts rather than the people who build them, and it is the kind of solution that changes how a team works rather than what a developer writes. Which is why the readme's preview status and its disclaimer sit together in the same document. The samples are patterns to learn from and code to copy, provided as is, and being explicit about both halves is what makes them useful rather than a false promise of supported components. ## Conclusion Adopt sp-dev-solutions if you are building SharePoint or Microsoft 365 applications and want a working reference rather than a specification to read. Do not adopt it as a dependency, because these are samples meant to be copied into and modified, and the readme is explicit that they are in preview and being updated. Before you start, read the contribution guidance if you plan to contribute rather than consume, because new solutions have to meet a stated standards criteria, and check the preview status before you base production work on any of them. ## FAQ ### What is the pnp/sp-dev-solutions repository? It is a collection of SharePoint solution samples from the Microsoft 365 Platform Community, containing end-to-end solutions with all the components needed for productivity scenarios, plus modules and patterns that developers can reuse in their own solutions. It also accepts community contributions. ### Which SharePoint scenarios do the sp-dev-solutions samples cover? Change requests, column formatting, contact and organisation management, link visuals with custom Handlebars templates, multilingual pages based on user language preference, the Pages API for getting and editing SharePoint Pages, inventory checkout and reservation, a Site Designs Studio for managing designs in the browser, a team out-of-office tracker, and a modern search experience with its own custom renderers. ### How do I build and preview one of the sp-dev-solutions samples? Clone the repository, change into the folder for the solution you want, run npm install there because each solution is an independent project, and then run gulp serve to preview the web parts in SharePoint Workbench, which is the hosted test harness inside a SharePoint site. ### Are the sp-dev-solutions samples production ready? The readme states they are currently in preview and undergoing further updates to improve quality and add capabilities, based on feedback. It also carries a disclaimer that the code is provided as is, without warranty of any kind, express or implied. ### What is required to contribute a new solution to sp-dev-solutions? For a new solution you will want to review the solutions standards criteria for inclusion, and for any pull request the readme asks you to read the contribution guidance in the .github directory first. The samples themselves come from the feature teams, the Microsoft 365 Platform Community core team, or the wider community. ## Sources - [Issues](https://github.com/pnp/sp-dev-solutions/issues) - [pnp/sp-dev-solutions on GitHub](https://github.com/pnp/sp-dev-solutions) - [README](https://github.com/pnp/sp-dev-solutions/blob/master/README.md) - [Releases](https://github.com/pnp/sp-dev-solutions/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pnp-sp-dev-solutions