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

Debugging deployed solutions #1386

Closed
nero120 opened this Issue Feb 21, 2018 · 19 comments

Comments

Projects
None yet
5 participants
@nero120

nero120 commented Feb 21, 2018

  • 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.

@VesaJuvonen VesaJuvonen self-assigned this Feb 22, 2018

@nero120

This comment has been minimized.

nero120 commented Apr 10, 2018

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!

@nero120

This comment has been minimized.

nero120 commented Apr 19, 2018

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

@nero120 nero120 closed this Apr 19, 2018

@waldekmastykarz

This comment has been minimized.

Member

waldekmastykarz commented Apr 21, 2018

You're welcome @nero120!

@nero120

This comment has been minimized.

nero120 commented Aug 21, 2018

@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

This comment has been minimized.

Member

waldekmastykarz commented Aug 21, 2018

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

This comment has been minimized.

nero120 commented Aug 21, 2018

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

This comment has been minimized.

Member

waldekmastykarz commented Aug 21, 2018

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

This comment has been minimized.

nero120 commented Aug 21, 2018

Thanks Waldek, that's awesome! 😃

@waldekmastykarz

This comment has been minimized.

Member

waldekmastykarz commented Aug 25, 2018

@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

This comment has been minimized.

nero120 commented Sep 3, 2018

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

@waldekmastykarz

This comment has been minimized.

Member

waldekmastykarz commented Sep 3, 2018

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

@nero120

This comment has been minimized.

nero120 commented Sep 4, 2018

We're currently only serving UK users so not much advantage in using the CDN as yet. It's on our list to look at in future.

@waldekmastykarz

This comment has been minimized.

Member

waldekmastykarz commented Sep 5, 2018

Good reasoning! Serving from SharePoint gives you simplicity of deployment but has other drawbacks, like frequent expiration

@shaipetel

This comment has been minimized.

shaipetel commented Sep 5, 2018

Hey, I have had the same challenge with other platforms before SPFx and used this approach which works in all of them as well as with our SPFx products:

Assuming you store all your scripts on an external CDN, like: https://cdn.company.com

All you need to do is have an instance of IIS running which holds a complete copy of the CDN with un-minified versions.

in our case, we use the local developer machine. But you may have 1 server shared to all developers.
you will need to install all SSL certificates on it so that it can respond correctly to "cdn.company.com"

When a developer needs to trace or debug a production behavior he cannot reproduce on his own dev environment, he will use a client PC and change the hosts file to point "cdn.company.com" to the IP of that private IIS server that holds the un-minified files.

Then, he can debug your un-minified code from your PC, while others using the product are still using the public production minified protected servers.

In our in-house dev process it is a bit more complicated, with http handler that can identify which version of the file to serve to the client and automatic build/deploy process that puts the right files in the right servers so of course you can streamline this more, but that is the core of our approach which I recommend using.

Hope this helps, I think this is a fairly straight forward solution with no need a change in SPFx, but it only works if you use a CDN, which I can't recommend enough for many other reasons!

Note: in SPFx we produce an un-minified file by running "gulp" without "--ship" flag, in case it wasn't clear.

@nero120

This comment has been minimized.

nero120 commented Sep 6, 2018

Very cool idea, thanks @shaipetel!

@waldekmastykarz

This comment has been minimized.

Member

waldekmastykarz commented Sep 7, 2018

Wouldn't it be easier to use a proxy like Fiddler and rewrite responses to serve dev files (assuming you don't have anything in place yet and want an easy solution)?

@shaipetel

This comment has been minimized.

shaipetel commented Sep 7, 2018

@waldekmastykarz I don't see how that is easier than changing the hosts file, but its a personal choice I guess. I do see your suggestion as a very good option for people who can't spin up a dev server and automate the publishing to it easily.

We have been doing it for years and have a production end point, "preview" and dev end points, and it takes little to no effort to switch between them on any computer you need to debug something or test a latest beta, without the need to install anything on the end user PC.

Also, like many vendors, our production is configured to block map files / un-minified files to keep them private (some vendors just don't publish them to the production at all), so that wouldn't work since the files are simply not there.

Like I said, I simplified it to pass a point - our actual set up is much more complex then that.
One advantage my approach has is that you are free to push dev/debug files to your dev server while investigating or trying to fix the bug. You can also test your fix on the live environment before you publish it, whereas your suggestion is good perhaps to be able to view the un-minified file, but if you push a change to ensure a fix works or add more log data - you will have to push it to your production servers (unless I misunderstood what you suggest).

Bottom line, I think we both agree that there are perfectly good ways to handle this without a need for SPFx to add this to the platform. Right?

@waldekmastykarz

This comment has been minimized.

Member

waldekmastykarz commented Sep 8, 2018

Until setups, like the one you're using become a commodity, there will be a need for an easy way to debug production code. Also, there is a big group of organizations who own the source code and don't mind publishing source map next to their production code.

Different organizations have different requirements and different ways of handling things. It would be good if SPFx covered the most common 80-90% of scenarios and offered flexibility for everyone else to implement their advanced setups.

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