SharePoint
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: https://github.com/SharePoint/sp-dev-docs/issues/467#issuecomment-284631927

416 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Waldek Mastykarz shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    Thanks for your feedback! Just a note to let you know that this is absolutely in our roadmap and we are planning to address this request in future. Good to have though also the vote counts, so that we understand the demand around the request, which helps on prioritizing our internal work.

    21 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • 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.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Looking forward to this feature. Would be great to understand how this is intended on being delivered and what scenarios it will support. Is there any chance of getting some further information on this enhancement to SPFx?

      ← Previous 1

      Feedback and Knowledge Base