Debugging PCF in Typescript

I see a lot of people lately started debugging PCFs by using Fiddler Autoresponder which is awesome and it’s definitely a way to do it.

If you are still one of those that are not using Fiddler when debugging your controls you should definitely need to read a deep-dive article by Diana Birkelbach which will guide you on how to set up Fiddler for the first time.

Debugging with Fiddler is a huge time saver for every developer out there, but what happens when it’s not enough.

Issues

You have that is using modern features like async/await pattern that is almost unreadable when translated to Javascript.

You separated complex control logic across multiple TypeScript files to make it more readable, but in the end, it’s bundled in a single file and you lost that readability when debugging.

You have a critical data related issue on the production environment and you need to debug it there, but there is only production ready minified code that can’t be debugged.

Solution

All the issues mentioned abouve can cause a lot of headaches when you are developing complex controls, but luckily there is always a tool that can help you with all the problems.

The answer to your problems is TypeScript’s feature called Source Map.

Source Map

Source Map is a feature that allows us to debug through our TypeScript files rather than generated JavaScript.

Those files basically contain all the code from your TypeScript files inside one bundled file which is pretty much unreadable for a human, but machines can do some magic with them.

An important thing to mention here is that your whole TypeScript code is copied to the source map file inside sourcesContent node.

When using Source Maps you can easily open your TypeScript files in dev tools of your choice and set breakpoints in them to start the much easier debugging session through much more readable TypeScript code.

Generate Source Map file

Now when we know what we need it’s time to make it work with the PCF project.

The first thing we need to do is instruct the compiler to generate source maps for us every time we make a change in our code.

This is a pretty straightforward process and it requires only one simple property in the tsconfig.json file located in the root folder of our project.

We need to add sourceMap property to the compilerOptions object inside the JSON file and set the value to true.

Your JSON should look something like this:

This was the easy part, but most of the people are stuck here because after the build source map file is not generated.

We need to do one more thing to make it work.

Modify the webpack config

Since PCF is using webpack as a bundler tool, we need to instruct it too that we want to use source maps because it’s not initially set up there.

Webpack configuration is quite hard to find in your project and that’s why most people fail in this step.

Configuration is hidden deep in the node_modules folder.

Path to the configuration file is:

node_modules/pcf-scripts/webpackConfig.js

Once you found the file open it and locate the oobConfig object.

You need to define new property inside this object called devtool and set the value to source-map like it’s shown in line number 5.

After that you are ready to generate the source map file.

Run a simple npm run build command and you should see that the bundle.js.map file is generated in command line output.

You can find those files in out/controls/<CONTROL_NAME> folder.

One more thing to check after the build is bundle.js file and search for one line at the end of the file.

//# sourceMappingURL=bundle.js.map

This line indicates a reference to the source map file that will be used in this JavaScript file.

Now we have everything to start debugging with the TypeScript files, but there is again a catch before we can actually do it.

If you try to pack the control and deploy it as a solution to the environment you will fast realize that you can’t find TypeScript files in the dev tools inside the browser.

The answer is because the source map was not packed inside the solution and deployed to the environment. There is an option called inline source map that will basically pack the whole source map file inside the bundle.js file.

That’s not a good practice because the size of the source map is most of the time larger than the original code size.

This is where Fiddler comes to the rescue and if you didn’t use Fiddler before please take a look at the post mentioned in the first section before you proceed with this article.

Fiddler Configuration

We need to inject the bundle.js.map file inside the browser to make everything work.

You need to create a simple new rule in Auto Responder rule.

Matchregex:(?inx).+bundle.js.map$
Action<LOCAL_PATH_TO_bundle.js.map>

With this, you are finally ready to jump to the browser and test the source maps.

Make sure that Fiddler’s Auto Responder is running and clear the browser cache before opening the form that has PCF control on it.

Once you open Dev Tools (Ctrl + Shift + I on Chrome/Edgium) you should navigate to the Sources tab.

You should see pcf_tools_<RANDOM-GUID> node there. When you expand it you should find all your TypeScript files there.

Open one of those files set a breakpoint and trigger the action that will hit that breakpoint.

Well done, you are finally debugging your TypeScript files.

Conclusion

This article showed you one more trick with Fiddler’s Auto Responder feature that will help you to speed up your development process, but also save your time when debugging when trying to find what causes the bug in the production environment in a more continent way.

Important things to remember are that source maps are not there with the default project configuration, but can be easily added when you get used to it.

I mentioned an inline source map that can be used without Fiddler, but it’s not a good idea to pack code one more time to the bundle.js file, definitely not in a production environment since the file size of the control is doubled.

I hope that from now on you will most likely stick with Fiddler debugging and use debugging harness less frequently.

Keep making great PCF controls!

One thought on “Debugging PCF in Typescript

  1. Pingback: Debugging PCF in Typescript - 365 Community

Comments are closed.