Sp-dev-docs: Module 4 Deploy to CDN, Webpart failed to render with no error

Created on 20 Aug 2016  ยท  12Comments  ยท  Source: SharePoint/sp-dev-docs

I followed all steps, confirmed JS and json assets (3 files) were uploaded to CDN correctly. The container path was resolved. It appears the deploy-azure-storage.json configuration entries are correct.
Uploading files '_/_.' from directory './temp/deploy/' to Azure
Upload complete!
But the web part is not rendering, only the web part title displayed. I don't have any explicit error. The JS did not load. The app package was properly uploaded after the CDN update.

I did receive a warning for Gulp package-solution. The specific file was created by the build task with no additional editing.
Warning - [package-solution] Ignoring manifest due to validation error (c:\coderepo\helloworld-webpart\dist\helloworld-webpart.stats.json)

I think the issue is with the write-manifests.json. I tried several forms. What is the correct string format for cdnBasePath? Can we show a sample in the tutorial?
"cdnBasePath": "https://xxxxx.blob.core.windows.net"

docs bug-suspected

All 12 comments

cdnBasePath is the one you associated with your Azure storage account. Something like this: http://cdn-endpoint.azureedge.net/blob-container/

I see the 3 files on the container in Azure but the web part shows error in the dev tools: with even though no file has that anymore.
Failed to load resource:https://gallive.sharepoint.com/sites/Dev/SitePages/%3C!--%20PATH%20TO%20CDN%20--%3E/hello-world.bundle_3a34e0d89c60058470b26347b081354d.js
the server responded with a status of 500 (Internal Server Error)

Have you tried running:

$ gulp bundle --ship

before uploading your scripts to Azure? The --ship argument makes SPFx build production version of your scripts with the CDN URLs. You can verify the contents of the scripts by checking the files in the ./temp/deploy folder after running that task.

I did. I also saw the files on my Azure container. the issue is that the
web part had a bad reference to that container.

On Mon, Aug 22, 2016 at 12:07 AM, Waldek Mastykarz <[email protected]

wrote:

Have you tried running:

$ gulp bundle --ship

before uploading your scripts to Azure? The _--ship_ argument makes SPFx
build production version of your scripts with the CDN URLs. You can verify
the contents of the scripts by checking the files in the _./temp/deploy_
folder after running that task.

โ€”
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/SharePoint/sp-dev-docs/issues/36#issuecomment-241316045,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE0h04F_Y-jYICw08jgKiKPyaNvvtqpfks5qiS6HgaJpZM4JpJck
.

Ofer Gal


ืœืคื ื™ ื”ืคืฆืช ืฉืจืฉืจืช, ื ื ืžื—ืงื• ืืช ืฉืžื™ ื•ื›ืชื•ื‘ืชื™ ืžื”ื“ื•ื"ืœ,
ื›ื“ื™ ืฉื”ืคืจื˜ื™ื ืœื ื™ื’ื™ืขื• ืœื—ื•ืจืฉื™ ืžืจืขื™ืŸ ื‘ื™ืฉื™ืŸ ื‘ืจื—ื‘ื™ ื”ืื™ื ื˜ืจื ื˜

Running gulp bundle --ship did fix my problem. without gulp bundle, the 5766da51-09e3-4c88-af42-093bce935100.json file contains internalModuleBaseUrls with the CDN Path token. Afterwards, it was properly populated from the write-manifest file.

Should the tutorial 4 documentation be updated to include this step? Currently, this command was not mentioned.

Chaks - more feedback on the tutorial 4 / CDN steps.

Yes that helped :+1: and also adding the https in "cdnBasePath": "https:// (My bad)

The command gulp --ship and the running gulp deploy-azure-storage --ship is supposed to build, bundle and deploy the web part assets respectively. You shouldn't need to run gulp bundle --ship.

The deploy-azure-storage command will always look for files in the temp/deploy folder which you would have if you had run gulp --ship as described above.

@chakkaradeep I also needed to do the gulp bundle --ship. Without that it was still referring to

Wiki for the tutorial 4 was updated Wed evening / yesterday (depending on your timezone) with the additional step. Thanks everyone for your input. We'll update the tutorials when there will be possible updates with the native package.

Closing this now as a tutorial bug, which has been closed.

This also doesn't work unless you do:

gulp package-solution --ship

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues

Was this page helpful?
0 / 5 - 0 ratings