Improved CSS Debugging in SharePoint Framework 1.20
Since the SharePoint Framework was released, I sometimes banged my head against the wall. Why are there no source maps for my SASS and CSS files? I learned to live with it until I had to fix a really old web part I had not touched in years and upgrade it to SharePoint Framework 1.20.
Imagine you wrote a web part when IE11 was still a concern for our customers. Now, you want to update the code base, but without source maps, it’s like trying to remember a dream you had years ago.
In this special case, a better quick links web part retrieved all the information from a centralised Database for the whole intranet. It is even more complex because it supports all the different variants.
As you can imagine, a lot of CSS is involved in supporting all these available variants and, on top of that, support for IE11. Of course, multiple CSS files were involved in that.
Finally Source Maps
Something has changed dramatically since SharePoint Framework 1.19.0. Source Maps are now displayed correctly in the browser CSS inspector. Before 1.19.0, the inspector showed only the style tag. This was caused by the build chain, which stripped the source map from the CSS when rendered in SharePoint.
I first recognised the change in behaviour when I looked at a sample web part based on SharePoint Framework 1.20. Interestingly, the source maps issue with CSS files was already fixed in version 1.19.
Now, it tells you the exact location of your CSS/SASS file, just as source maps should work.
The full source is presented in the browser like this:
Files are loaded from the local file system. The webpack origin of all the other files is also included in the SharePoint Framework and exposed in the developer tools.
Whatever I tried to improve the gulp, webpack, or postcss autoprefixer configuration, you cannot enable source maps when you use the default build chain.
What has changed?
I assume the upgrade and support for webpack version 5 have fixed this issue. Since the release notes haven’t mentioned this fix, it hugely benefits developers.
Suppose you do not plan to update your SharePoint Framework solutions because only features are included without affecting your solution. This under-the-hood fix is one reason for upgrading to the newest version of SPFx.
So far, I have tried to enable source maps to work on older versions, pre-SPFx 1.19.0, but I haven’t succeeded.
I recommend updating to something other than 1.19.0 and going straight to SharePoint Framework 1.20. This release also fixes the [object]—object webpack issue, which I reported on how to work around.
Check out the SharePoint Framework Release notes and Roadmap on the official documentation. Microsoft 365 CLI can help you to upgrade your solution to the latest version.