Debugging deployed solutions

[nero120]

• Question
• Typo
• Bug
• Additional article idea

Is there any way currently to make debugging deployed solutions (packaged via gulp bundle --ship and gulp package-solution --ship) any easier? If an error is thrown it is next to impossible to debug the uglified javascript. Perhaps this is simply a case of including source maps for a production build by extending webpack? If anyone has any guidance around this I'd appreciate it.

[nero120]

Hi @VesaJuvonen, any updates on this or alternative approaches to debugging issues in production? We're getting inconsistent/intermittent issues when users navigate to a page with our SPFX webpart which are very hard to diagnose, and the lack of any usable stack trace info in the browser console is really unhelpful!

[russgove]

this was just published https://blog.mastykarz.nl/debug-production-version-sharepoint-framework-solution/?utm_source=collab365&utm_medium=collab365today&utm_campaign=daily_digest

[nero120]

Thank you @russgove! That link was very useful, and thanks @waldekmastykarz for the great blog post. 😄

[waldekmastykarz]

You're welcome @nero120!

[nero120]

@waldekmastykarz although your method helped, the biggest issue is that any logging in Azure Insights is uglified and useless (see #1955). Do you know of any way to disable uglifying the js when using prod mode?

[waldekmastykarz]

What you really want is not to not-uglify JS as that would impact the performance of your scripts, but instead to have the production build to include source maps which can be then used to map your uglified code that you run in production to the original code that you can actually read. At this moment, source maps are explicitly removed from the production build, but it would be a fair requests to the SharePoint engineers to allow us to include them if we choose so.

/cc: @VesaJuvonen

[nero120]

But even with source maps, an exception stack trace logged in Insights would still look like:

TypeError: Cannot read property 'preferredName' of undefined
    at https://xxx.sharepoint.com/sites/xxx/ClientSideAssets/063b99d1-2b82-4948-b777-c4d8f7f47c2e/home-page-web-part_2414fd410ecad3ec78fb91eeb3debc75.js:42:95917
    at Array.map (<anonymous>)
    at e.<anonymous> (https://xxx.sharepoint.com/sites/xxx/ClientSideAssets/063b99d1-2b82-4948-b777-c4d8f7f47c2e/home-page-web-part_2414fd410ecad3ec78fb91eeb3debc75.js:42:95765)
    at r (https://xxx.sharepoint.com/sites/xxx/ClientSideAssets/063b99d1-2b82-4948-b777-c4d8f7f47c2e/home-page-web-part_2414fd410ecad3ec78fb91eeb3debc75.js:42:73269)
    at Object.next (https://xxx.sharepoint.com/sites/xxx/ClientSideAssets/063b99d1-2b82-4948-b777-c4d8f7f47c2e/home-page-web-part_2414fd410ecad3ec78fb91eeb3debc75.js:42:72604)
    at a (https://xxx.sharepoint.com/sites/xxx/ClientSideAssets/063b99d1-2b82-4948-b777-c4d8f7f47c2e/home-page-web-part_2414fd410ecad3ec78fb91eeb3debc75.js:42:72346)

wouldn't it? Improved performance doesn't much matter if we can't support these applications in production...

[waldekmastykarz]

You basically have two options: you can disable mangling, which will put all code in one line and remove white spaces retaining the original names, or disable the uglify plugin altogether. Here is how to do both (put one of the blocks but not both in gulpfile.js)

'use strict';

const gulp = require('gulp');
const build = require('@microsoft/sp-build-web');
build.addSuppression(`Warning - [sass] The local CSS class 'ms-Grid' is not camelCase and will not be type-safe.`);

// 1. disable mangling
build.configureWebpack.mergeConfig({
    additionalConfiguration: (generatedConfiguration) => {
        generatedConfiguration.plugins.forEach((plugin, i) => {
            if (plugin.options && plugin.options.mangle) {
                plugin.options.mangle = false;
            }
        });

        return generatedConfiguration;
    }
});

// 2. disable the uglify plugin altogether
build.configureWebpack.mergeConfig({
    additionalConfiguration: (generatedConfiguration) => {
        generatedConfiguration.plugins.forEach((plugin, i) => {
            if (plugin.options && plugin.options.mangle) {
                generatedConfiguration.plugins.splice(i, 1);
            }
        });

        return generatedConfiguration;
    }
});

build.initialize(gulp);

[nero120]

Thanks Waldek, that's awesome! 😃

[waldekmastykarz]

@nero120 Are you deploying your bundles to the Office 365 Public CDN? If so, there might be another issue, that's preventing you from logging exceptions in production altogether.

What I've seen is, that if I get an exception in a solution deployed to Office 365 Public CDN, all I get logged in AI is:

The browser's same-origin policy prevents us from getting the details of this exception. Consider using 'crossorigin' attribute.

So no matter if your code is minified or not, nothing is getting logged actually. Is this what you're seeing as well of haven't you tested in yet or using a different setup?

I logged a separate issue for that #2421. Let's see if we can get more info on that.

[nero120]

@waldekmastykarz we are deploying to the ClientSideAssets library so have not seen that particular error before. Thanks for the heads up though.

[waldekmastykarz]

@nero120 just out of curiosity: any particular reason why you're not using the Office 365 Public CDN?