New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for library packages #467

Closed
waldekmastykarz opened this Issue Mar 4, 2017 · 14 comments

Comments

Projects
None yet
8 participants
@waldekmastykarz
Member

waldekmastykarz commented Mar 4, 2017

Category

  • Question
  • Typo
  • Bug
  • Enhancement / Suggestion
  • Additional article idea

Expected or Desired Behavior

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.

Observed Behavior

Currently, working with library packages works only with the local workbench. At this moment, it's not possible to generate a package for a project with a library component type. Having generated a library package myself, and deployed it to the App Catalog, the library package causes an error in SharePoint stating that component type Library is not supported. As a result no custom web parts show in the toolbox.

Steps to Reproduce

  • create a solution with a component type library
  • run $ gulp package-solution
    • error: Component type 'Library' not recognized. Skipping manifest.
@vignes412

This comment has been minimized.

Show comment
Hide comment
@vignes412

vignes412 Mar 7, 2017

we can import modules in three methods

FIRST::Using Config-->config.json and change

 "externals": {
    "jquery": "https://code.jquery.com/jquery-3.1.0.min.js",
    "OwlCarousel":{
      "path":"./node_modules/react-owl-carousel/lib/OwlCarousel.min.js",
      "globalName":"OwlCarousel"
    },
    "Slider":{"path":"./node_modules/react-slick/lib/slider.js",
    "globalName":"Sliders"}
  },

SECOND:: npm install @types/youtube-api-search --save

THIRD ::

 `npm install typings` 

`typings install dt~youtube-api-search -global --save`

sometimes dt~ is neccessary sometimes it is not necessaary

vignes412 commented Mar 7, 2017

we can import modules in three methods

FIRST::Using Config-->config.json and change

 "externals": {
    "jquery": "https://code.jquery.com/jquery-3.1.0.min.js",
    "OwlCarousel":{
      "path":"./node_modules/react-owl-carousel/lib/OwlCarousel.min.js",
      "globalName":"OwlCarousel"
    },
    "Slider":{"path":"./node_modules/react-slick/lib/slider.js",
    "globalName":"Sliders"}
  },

SECOND:: npm install @types/youtube-api-search --save

THIRD ::

 `npm install typings` 

`typings install dt~youtube-api-search -global --save`

sometimes dt~ is neccessary sometimes it is not necessaary

@waldekmastykarz

This comment has been minimized.

Show comment
Hide comment
@waldekmastykarz

waldekmastykarz Mar 10, 2017

Member

@vignes412 this issue is not about referencing regular Node packages but using SharePoint Framework libraries which are a specific type of component.

Member

waldekmastykarz commented Mar 10, 2017

@vignes412 this issue is not about referencing regular Node packages but using SharePoint Framework libraries which are a specific type of component.

@amishra0909

This comment has been minimized.

Show comment
Hide comment
@amishra0909

amishra0909 May 9, 2017

Thanks for the feedback @waldekmastykarz. We do not support third party "Library" components currently but we have this feature added and tracked in our backlog. I am closing this issue for now and you can use our UserVoice to post your feature requests in future. Here is the link to the UserVoice: https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform

amishra0909 commented May 9, 2017

Thanks for the feedback @waldekmastykarz. We do not support third party "Library" components currently but we have this feature added and tracked in our backlog. I am closing this issue for now and you can use our UserVoice to post your feature requests in future. Here is the link to the UserVoice: https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform

@amishra0909 amishra0909 closed this May 9, 2017

@pgonzal

This comment has been minimized.

Show comment
Hide comment
@pgonzal

pgonzal Jun 24, 2017

Following up on this: The "client-side libraries" feature is mainly used by the SPFx runtime itself. It enables dynamic side-by-side versioning, i.e. it allows your library to be modeled as a client-side component with a manifest and a bundle. When new versions of your library are deployed, other already deployed consumers (e.g. web parts or extensions) will be automatically linked at runtime to the most recent compatible version number.

Currently we don't officially support this for third parties. It is a somewhat advanced approach that requires you to:

  • Set up separate TypeScript project folders, since each library is a separate NPM package
  • Use a tool like Rush to symlink your project folders during development, because if you try to use "npm link" you are likely to encounter a TypeScript compiler bug (that will be fixed soon)
  • Deploy your libraries separately to the App Catalog, since "gulp package-solution" does not span multiple project folders
  • Think carefully about your runtime API contracts, since there is a possibility that components might get linked to a different library version than they were tested with

I have not personally heard anyone asking for this feature specifically. What most people seem to want is one of these two scenarios:

  1. I have two web parts, and I want to share some code between them; and (less commonly)
  2. ...when I load only one of my web parts, I want to improve performance by NOT loading the other web part's code

Both of these scenarios have a much simpler solution than client-side libraries: We're working on a feature that will allow multiple web parts (from the same project) to be packed into a single bundle. This means that if they share code, only one copy of the code will be on the page. Also there will not be duplicate instances of your singleton objects (as happens with libraries packed into separate bundles). Since everything builds together as one project, this approach will avoid the complexity that I mentioned above. And if you want to avoid loading unnecessary code, you can use Webpack chunks just like with a single-web-part project.

I suspect that this will meet the needs of the vast majority of people asking about library code. The one exception would be if someone was distributing a shared platform API and wanted to push out updates without having to rebuild already deployed components that rely on it (like what SPFx does). So far I haven't heard any serious requests for that yet, but if so, we'd be interested to hear about it. :-)

@VesaJuvonen @waldekmastykarz @nickpape-msft @patmill @iclanton @qz2017

pgonzal commented Jun 24, 2017

Following up on this: The "client-side libraries" feature is mainly used by the SPFx runtime itself. It enables dynamic side-by-side versioning, i.e. it allows your library to be modeled as a client-side component with a manifest and a bundle. When new versions of your library are deployed, other already deployed consumers (e.g. web parts or extensions) will be automatically linked at runtime to the most recent compatible version number.

Currently we don't officially support this for third parties. It is a somewhat advanced approach that requires you to:

  • Set up separate TypeScript project folders, since each library is a separate NPM package
  • Use a tool like Rush to symlink your project folders during development, because if you try to use "npm link" you are likely to encounter a TypeScript compiler bug (that will be fixed soon)
  • Deploy your libraries separately to the App Catalog, since "gulp package-solution" does not span multiple project folders
  • Think carefully about your runtime API contracts, since there is a possibility that components might get linked to a different library version than they were tested with

I have not personally heard anyone asking for this feature specifically. What most people seem to want is one of these two scenarios:

  1. I have two web parts, and I want to share some code between them; and (less commonly)
  2. ...when I load only one of my web parts, I want to improve performance by NOT loading the other web part's code

Both of these scenarios have a much simpler solution than client-side libraries: We're working on a feature that will allow multiple web parts (from the same project) to be packed into a single bundle. This means that if they share code, only one copy of the code will be on the page. Also there will not be duplicate instances of your singleton objects (as happens with libraries packed into separate bundles). Since everything builds together as one project, this approach will avoid the complexity that I mentioned above. And if you want to avoid loading unnecessary code, you can use Webpack chunks just like with a single-web-part project.

I suspect that this will meet the needs of the vast majority of people asking about library code. The one exception would be if someone was distributing a shared platform API and wanted to push out updates without having to rebuild already deployed components that rely on it (like what SPFx does). So far I haven't heard any serious requests for that yet, but if so, we'd be interested to hear about it. :-)

@VesaJuvonen @waldekmastykarz @nickpape-msft @patmill @iclanton @qz2017

@waldekmastykarz

This comment has been minimized.

Show comment
Hide comment
@waldekmastykarz

waldekmastykarz Jun 28, 2017

Member

I think there is still need to deploy and manage separate libraries of common code. I suspect people haven't been asking for it, because it's still very early and many are yet to start building solutions on the SharePoint Framework. In the past it was a common scenario for developers to split a solution into multiple WSPs which could be managed separately. I think the same requirement still applies to the SharePoint Framework, particularly for bigger projects that would contain dozens of web parts and extensions.

Member

waldekmastykarz commented Jun 28, 2017

I think there is still need to deploy and manage separate libraries of common code. I suspect people haven't been asking for it, because it's still very early and many are yet to start building solutions on the SharePoint Framework. In the past it was a common scenario for developers to split a solution into multiple WSPs which could be managed separately. I think the same requirement still applies to the SharePoint Framework, particularly for bigger projects that would contain dozens of web parts and extensions.

@pgonzal

This comment has been minimized.

Show comment
Hide comment
@pgonzal

pgonzal Jun 29, 2017

@waldekmastykarz Just to clarify, are you saying that this seems like something people will eventually want, as their needs become more sophisticated (which we agree)? Or are you saying that you need this for a real project right now, i.e. our other solution won't work for you?

I'm just trying to figure out how we should prioritize it against our other work.

pgonzal commented Jun 29, 2017

@waldekmastykarz Just to clarify, are you saying that this seems like something people will eventually want, as their needs become more sophisticated (which we agree)? Or are you saying that you need this for a real project right now, i.e. our other solution won't work for you?

I'm just trying to figure out how we should prioritize it against our other work.

@waldekmastykarz

This comment has been minimized.

Show comment
Hide comment
@waldekmastykarz

waldekmastykarz Jun 29, 2017

Member

First one: people will need this eventually. The number of votes on UserVoice are a good indication on how desired this capability is.

Member

waldekmastykarz commented Jun 29, 2017

First one: people will need this eventually. The number of votes on UserVoice are a good indication on how desired this capability is.

@arnieraju

This comment has been minimized.

Show comment
Hide comment
@arnieraju

arnieraju Jul 21, 2017

Thanks for driving this Waldek. Depending on what we are trying to achieve, we have been using ScriptEditor, ContentEditor web parts, and Custom Actions to make common libraries available to different client side apps on a page. The first two of which won't work in the new world of Modern Pages and all of which provide a disjointed and hacky development and deployment experience.

It would be great to have an SPFx way for approaching how we package and deploy common libraries.

arnieraju commented Jul 21, 2017

Thanks for driving this Waldek. Depending on what we are trying to achieve, we have been using ScriptEditor, ContentEditor web parts, and Custom Actions to make common libraries available to different client side apps on a page. The first two of which won't work in the new world of Modern Pages and all of which provide a disjointed and hacky development and deployment experience.

It would be great to have an SPFx way for approaching how we package and deploy common libraries.

@pgonzal

This comment has been minimized.

Show comment
Hide comment
@pgonzal

pgonzal Jul 28, 2017

Suppose you have three pieces of code:

  • Web Part 1
  • Web Part 2
  • Common Library

In your scenario, would you want to go through these steps separately for each piece: compile, package, upload to App Catalog, get tenant admin approval? Would each piece have its own dev team?

If so, how would you handle mismatches, e.g. where Web Part 1 requires Common Library version 2.0.3 but Web Part 2 requires Common Library version 1.5.6?

The approach I was advocating instead would have all three pieces compiled together and packaged into a single ".spkg" file.

pgonzal commented Jul 28, 2017

Suppose you have three pieces of code:

  • Web Part 1
  • Web Part 2
  • Common Library

In your scenario, would you want to go through these steps separately for each piece: compile, package, upload to App Catalog, get tenant admin approval? Would each piece have its own dev team?

If so, how would you handle mismatches, e.g. where Web Part 1 requires Common Library version 2.0.3 but Web Part 2 requires Common Library version 1.5.6?

The approach I was advocating instead would have all three pieces compiled together and packaged into a single ".spkg" file.

@waldekmastykarz

This comment has been minimized.

Show comment
Hide comment
@waldekmastykarz

waldekmastykarz Aug 10, 2017

Member

I've been thinking about the case where all three are separate packages managed independently. This is common for large organizations who have a standard for things like logging, error handling or calling line of business applications that should be reused by all projects. So while the common library might not be managed by itself it would most likely be extended with required pieces when working on Web Part 1 or Web Part 2 which in fact are better to be seen seen as Project 1 and Project 2.

With regards to handling version conflicts: if v2 is not backwards compatible with v1 then major versions could be included in the package name, e.g. contoso-common-v1. Each major version would have a different ID and be deployed separately to the app catalog. If they are backwards compatible, then v2 could replace v1.

Member

waldekmastykarz commented Aug 10, 2017

I've been thinking about the case where all three are separate packages managed independently. This is common for large organizations who have a standard for things like logging, error handling or calling line of business applications that should be reused by all projects. So while the common library might not be managed by itself it would most likely be extended with required pieces when working on Web Part 1 or Web Part 2 which in fact are better to be seen seen as Project 1 and Project 2.

With regards to handling version conflicts: if v2 is not backwards compatible with v1 then major versions could be included in the package name, e.g. contoso-common-v1. Each major version would have a different ID and be deployed separately to the app catalog. If they are backwards compatible, then v2 could replace v1.

@VesaJuvonen

This comment has been minimized.

Show comment
Hide comment
@VesaJuvonen

VesaJuvonen Aug 10, 2017

Contributor

Just an additional comment on the @waldekmastykarz 's input. Mid-sized and larger enterprises were already doing this exact thing with farm solutions back in the on-premises days with similar version dependencies cross solutions.

Considering the fact that development projects can have tens of developers for one project, customers / partners create their own development processes to ensure that there are no version conflicts. Obviously using separately deployed code is not really recommended for smaller deployments due to the additional overhead, but even back in the days when was also personally working in the field, customer projects could have easily 30-40 web parts developed by different geographically located teams.

What would be interesting is to hear about the cases where the library model would be used and what sized projects are currently being built on top of the SharePoint Framework, so that we can internally evaluate the priority for this request.

Contributor

VesaJuvonen commented Aug 10, 2017

Just an additional comment on the @waldekmastykarz 's input. Mid-sized and larger enterprises were already doing this exact thing with farm solutions back in the on-premises days with similar version dependencies cross solutions.

Considering the fact that development projects can have tens of developers for one project, customers / partners create their own development processes to ensure that there are no version conflicts. Obviously using separately deployed code is not really recommended for smaller deployments due to the additional overhead, but even back in the days when was also personally working in the field, customer projects could have easily 30-40 web parts developed by different geographically located teams.

What would be interesting is to hear about the cases where the library model would be used and what sized projects are currently being built on top of the SharePoint Framework, so that we can internally evaluate the priority for this request.

@pgonzal

This comment has been minimized.

Show comment
Hide comment
@pgonzal

pgonzal Aug 10, 2017

Agreed. Releasing this feature is actually not particularly difficult, since it is what we already do internally for the SPFx packages. The challenge is that is a somewhat advanced model. It requires the kind of coordination you describe (which for us has turned out to be an involved process). We would need to document the model clearly, help people to understand whether it is appropriate for their problem, and give guidance to avoid "DLL hell".

That's the main reason I was waiting for to see whether the multiple-components-in-one-bundle alternative would suffice for most people. BTW I believe that one will be included in the next major SPFx release, if you want to give it a try for comparison.

pgonzal commented Aug 10, 2017

Agreed. Releasing this feature is actually not particularly difficult, since it is what we already do internally for the SPFx packages. The challenge is that is a somewhat advanced model. It requires the kind of coordination you describe (which for us has turned out to be an involved process). We would need to document the model clearly, help people to understand whether it is appropriate for their problem, and give guidance to avoid "DLL hell".

That's the main reason I was waiting for to see whether the multiple-components-in-one-bundle alternative would suffice for most people. BTW I believe that one will be included in the next major SPFx release, if you want to give it a try for comparison.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment