What if we could include source maps in SharePoint Framework packages
By generating source maps for the production builds of your SharePoint Framework solutions, you can debug them right there in production. But what if using source maps was even easier?
When things don’t work as expected
Despite the best intentions, sometimes things break. If it’s because of a bug or an unforeseen scenario, there is a chance that your solution might not work as expected. Once it happens in the production tenant, you want to fix it as quickly as possible.
Debugging issues in production is not without challenges. The SharePoint environment is being used by people doing their job. An issue in your solution, disrupts their productivity and sometimes even makes it impossible for them to work. What’s even worse, is that because you optimized your solution, its code is now unreadable for a human being making it even harder for you to find what is wrong.
Easily debugging production version of SharePoint Framework solutions
Recently, I wrote about how you can easily debug production versions SharePoint Framework solutions. By generating source maps, you can map the optimized code to the original code you wrote. Thanks to source maps, you can run the optimized code in the browser but set breakpoints and step through your original code, which is perfect if you have to find why your solution doesn’t work as expected.
By default, generating source maps in production builds is disabled. You can turn it on, by changing the build configuration slightly. As a result, each time the SharePoint Framework toolchain builds your code, it will also produce a source map.
Deploying SharePoint Framework assets to SharePoint
In one of the recent versions of the SharePoint Framework, Microsoft introduced the ability to include the solution assets in the generated SharePoint Framework package (.sppkg). When deploying such solution to the app catalog, SharePoint will automatically extract the asset files and deploy them to a designated document library in the same site as where the app catalog is located. If you have the Office 365 Public CDN enabled, these scripts will automatically be served from the Office 365 CDN, which will benefit your solution even further.
What if…
In my original article, where I introduced the idea of generating source maps for production code, I mentioned, that most likely you don’t want to share the source maps with everyone. After all, they contain the original code and you might not want to give away your intellectual property. This is especially the case, if you are an ISV or a consulting company. So to be able to benefit of source maps, you have to store them somewhere safe, where you can get them from if need be.
But what if you have an in-house IT department that builds solutions for your organization? Everything your IT department builds, your organization owns anyway. Storing source maps separately adds complexity to your IT processes. In such case, it would make perfect sense to be able to include the generated source maps in the .sppkg files. Whenever you had to debug your code, the web browser will automatically load the source map without any manual steps on your part.
Because source maps for SharePoint Framework solutions are stored in separate files, they don’t add to the size of the script bundles. Also, because source maps are used only when the developer tools in the web browser are turned on, regular users wouldn’t be downloading them. So the only impact of packaging source maps would be increased size of .sppkg files and a few hundred KB extra stored in the Office 365 CDN.
Maybe tomorrow
While it’s possible to reconfigure the build process to generate source maps for production builds, it turns out, that it’s not possible to have them automatically included in .sppkg files. For some reason, source maps are explicitly excluded from the packaging process, and there is no way to include them in the package without either changing the code of the build chain or updating the contents of the package yourself.
It would be helpful, if it was possible to use two simple options in the build process to choose if you want to generate source maps for your production builds and if so, if they should be included in the generated packages. What do you think, would it be worth a UserVoice entry?