Feedback by UserVoice

I suggest you ....

Add support for library packages in the SharePoint Framework

When building web parts I'd like to be able to extract common code to a separate library that can be shared amongst the different web parts.

Related issue on GitHub:

451 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Waldek Mastykarz shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

Thanks for your feedback! We’re happy to report that your suggestion was delivered as preview as part of the SharePoint Framework 1.8 release. See more details from the release notes – and from the official SharePoint dev documentation at This capability is currently in preview, but will be shipping close as is to production soon, so we are closing this already to ensure that the progress is noted.


Comments are closed
  • nate commented  ·   ·  Flag as inappropriate

    Hi SharePoint Dev Platform Team

    I note that you have the status set to "Working on it" though that is coming up 18 months ago. Has this feature been added to any of the drops up until now?

    I'm struggling to find reference to a finished feature that'd allow us to use the requested feature.

  • Henk ter Harmsel commented  ·   ·  Flag as inappropriate

    Sorry for the late reply, but I agree on that point. The purpose of the library we are creating however is only for product related activities in the SPFx webparts and extensions we are creating. For the more basic library material like for example logging we are using pnpjs and other libraries. If necessary we can always create a second library.

  • Andrew Connell commented  ·   ·  Flag as inappropriate

    If you want every single thing you build to only work in a SharePoint context, then this route makes sense. But if you want to leverage solutions that already exist for these problems that don't require a SharePoint solution, then going with the more non-SharePoint way is preferred. Simply a difference of opinions... I think this SharePoint-only mindset is what hurts the platform.

  • Henk ter Harmsel commented  ·   ·  Flag as inappropriate

    3th point to support spfx libraries. I am unable to use spfx component like @microsoft/sp-loader, @microsoft/sp-http etc in my library. I have managed to compile and bundle my library with tsc and webpack by adding these components as externals in webpack, but webpack is failing to load them in my webpart.

  • Henk ter Harmsel commented  ·   ·  Flag as inappropriate

    Another thing are externals used in your spfx library. When our npm package is included by an SPFx webpart, I don't want for example jQuery to get loaded twice, or even worse, not loaded, and I absolutely don't want it to get included in my library bundle to make sure it does exist. A solution is to give all users of my library instruction which libraries to include, but spfx already has a great solution for this problem.

  • Henk ter Harmsel commented  ·   ·  Flag as inappropriate

    Well, to start it would give us the possibility to use the sp-build-web rig to build our solutions the same way spfx is doing. When doing this without an spfx manifest.json it won't work. I'm not saying it can't be achieved with an NPM package, but doing this the SPFx way would make this easier and faster to setup, and would make the code a lot less error phrone. Also for example the translation files have their own .js files at this moment referenced in the .sppkg files. How are we going to reference this from a library? also, for me it would be fine if we could host these libraries in an Azure CDN and not have to upload an sppkg file, but I can imagine people would like to host it on multiple SharePoint environments with includeClientSideAssets set to true.

  • Andrew Connell commented  ·   ·  Flag as inappropriate

    I respectfully disagree... I don't see anything that SPFx would provide that can't be achieved with an NPM package. Everything you described can be done with an NPM package and it wouldn't require the library to be delivered BEFORE your component that consumes it is deployed.

  • Henk ter Harmsel commented  ·   ·  Flag as inappropriate

    @Andrew Connel, that might be true, but spfx supporting this would give us the possibility to create an spfx library, publishing it to Azure DevOps with npm and give everyone in our organization the possibility to use this library. In this library we can create some default base components, logging, translations, styles etc on the way we are used to with spfx webpart with sp-build already configured. I think it could be done with existing solutions, but SPFx supporting this would make this a lot easier.

  • Andrew Connell commented  ·   ·  Flag as inappropriate

    This (@CPritch on NOV 2,2018) is _EXACTLY_ my point for why I don't see a need for this in SPFx. There are existing solutions for this exact problem and this is how I'd handle it. If you use the same library code in multiple places, put it in a CDN and add an external reference in your config.json file.

  • CPritch commented  ·   ·  Flag as inappropriate

    For anyone interested we have managed to achieve this somewhat by importing our library code from a private npm server. Then at the package-solution step it will import all of our dependencies into the sppkg file.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Yes same my organization also has a comman service which is used by multiple webparts.

  • Mark Freeman commented  ·   ·  Flag as inappropriate

    We are a large org with 70K users and we want to implement a common global library of reusable services such as logging, error handling, API's etc to be reused by multiple apps, web parts etc. This feature is in the critical path for us.

← Previous 1

Feedback and Knowledge Base