8

Currently, the SharePoint Framework solutions are deployed as tenant wide app packages. Thereby, all instances of the web parts refer the JavaScript files from the CDN location specified in the packaged that is deployed in the app catalog. We need the ability to run Development, Staging and Production environments as different Site Collections in the same tenant. Is there a workaround for this?

I have tried deploying the app package to catalog, but updating only the instances I need (e.g. in Dev Site). But, the app instance update doesn't seem to do anything. The manifests are reflected in all sites, as soon as the new app package is uploaded to the catalog.

Improve this question

3 Answers 3

Reset to default
5

OK, I asjed this in the PNP-JS-COre meeting. Vesa said you can just change the settings in the config files to create a new package. So in config/package solution you can change the solution id and solution name to make it a distict package. Also change the paths Zipped-Package to give it a different file name so that you can have two versions in the app catalog.

Then you can set up an alternate cdnBasePath in write-manifest.json to point to the dev bundle.

Improve this answer
5
  • Thanks for following up on this. This is exactly what I ended up doing. I am yet to test this end-to-end, but I did some gulp tasks to automate most of these. I will push it to a GitHub repo and share the link soon. I also posted this on uservoice link
    – user2560429
    Commented Jun 13, 2017 at 23:15
  • 1
    cool, thanks. i'm testing this out my self, but manually. i'll be looking for your gulp task. btw: vesa also mentioned that they are working on a site collection level app catalog. sounds like that will help.
    – RussGove
    Commented Jun 14, 2017 at 0:53
  • Did you guys ever iron this one out? If I change the app name, id, filename and CDN base path in both my dev + test packages, they can be installed into the app catalog side-by-side just fine, but the test web parts will randomly serve up the dev versions on every second or third page refresh (by loading their scripts instead), and vice versa. Ensuring the dev + test packages have different versions doesn't fix the issue either. Any ideas? Do the web parts IDs need to be different too? Note: my dev + test packages are even installed to different site collections
    – user4545
    Commented Jul 5, 2017 at 9:32
  • did you run gulp clean before bundling your second deployment. If you don't do a clean it keeps old versions of the code in the bundle.
    – RussGove
    Commented Jul 5, 2017 at 20:34
  • Yep, but still no luck. I ultimately ended up having to change all the web part IDs too — once I did this, the web parts stopped randomly loading bundles from different packages / environments. This isn't ideal, as the web part IDs are referenced in our PnP provisioning scripts so they need to be updated each time we do a dev/test/prod build too.
    – user4545
    Commented Jul 6, 2017 at 1:14
3

Microsoft has now released a site collection app catalog -

enter image description here

The only limitation appears to be a lack of Application Lifecycle Management API support.

Improve this answer
1
0

To solve your problem you can do following workaround:

For Development:
I'll recommend here to use SharePoint workbench to develop your web part. This will pick webpart and scripts directly from your localhost, so you can modify scripts without impacting your App deployed in app catalog. You can access the workbench using following URL pattern:

https://[path_to_your_site]/_layouts/workbench.aspx

Staging/Production
Bundle the SPFx web part into .sppkg package and upload it to your App Catalog. Also, update the CDN with latest scripts files.

Using this way you can have two environment in same tenant for development as well as for production.

Improve this answer
8
  • but we would need to deploy the updated package to the app catalog to let users test it. also would need to deploy the test bundle to the cdn. how can we let users test the new version?.. we can create a separate folder in the cdn for the bundle, but can we have dev and test versions in the app catalog?
    – RussGove
    Commented Jun 1, 2017 at 23:27
  • I read your post and want to suggest that App version works in this case. I do have the same environment. In such case, I maintain app version. For me its working fine. The only thing is, you need to have a different scripts file. When you upload files to CDN make sure each app version will refer to its own scripts file. Check your <code>temp/deploy</code> where you can find the JS file. I am still trying to figure out how to use <code> gulp bundle --ship </code> to create each time a separate JS file.
    – ThinkB4Code
    Commented Jun 2, 2017 at 5:29
  • ok, i think i see. so you only ever have one version in the app catalog, right?
    – RussGove
    Commented Jun 2, 2017 at 10:42
  • I have tried changing the app version, but it doesn't work for me. As soon as i upload the new package with newer version to the app catalog, all web part instances across all site collections refer the newer version. Basically, updating individual app instances has no effect.
    – user2560429
    Commented Jun 2, 2017 at 22:27
  • And the workbench approach suggested by ThinkB4Code doesn't work for me either. Because, I need some of my business stakeholders to be able to see the development environment to get some feedback.
    – user2560429
    Commented Jun 2, 2017 at 22:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.