Hi SharePoint and React devs,

If you have a bit of experience with SPFx and/or React, you probably know that you can usually build your bundles with at least two configurations: DEBUG and PRODUCTION. In this post I want to tackle an issue I faced a couple times and once again recently.


Indeed, while, the DEBUG build is very handy while developing your app; it includes Webpack original sources (e.g. your TypeScript sources, …), not minified JS code, etc… Bundles built for PRODUCTION contains a version of the code that is minified, uglified, optomized for better runtime performance, etc…

In some cases, the PRODUCTION and DEBUG output can be different enough that, at runtime, it might break or behaves in an unexpected way.

As a reminder, in the case of SPFx, when you run gulp build or gulp bundle, by default you get a DEBUG build, in order to have a PRODUCTION build, you rather use gulp build –ship or gulp bundle –ship

On my side, when I work on a SPFx project, during development time, I usually use  DEBUG build and deploy a solution package that refers to the locally served JS assets. I guess it is a pretty common scenario

Two problematic cases

Let me present 2 cases I ran into in which everything worked just fine in DEBUG build and crashes miserably in PRODUCTION build config.

Case #1 SPFx localized strings results in different transpiled JS

In one of my projects, I needed to implement a service that takes a SPFx localized string key as parameter. To avoid passing the keys as strings at risk of mispelling it, I implemented the method so you can either pass the key as string or as an arrow function that return, let’s say strings.myKey. Let’s see a example of code:

Let’s run the exact same solution in both build configurations and let’s take a look at the value of the name resolver

In DEBUG build config


In PRODUCTION build config


Note: see in the code exhibit above how I handled the differences using two different regex patterns.

Case #2 React child has different form in DEBUG and PRODUCTION

One of my React components is implemented to handle only those of its children that are instances of a particular class. I implemented it this way:

Take a closer look at lines 21,22

It worked fine in DEBUG mode where the type’s name of a React child was the name of the type until I built it for PRODUCTION. In this configuration, the type’s name is minified so I had to adapt my code to make it work there as well…

Let’s see the difference with some logging done from both build configurations

In DEBUG build config


In PRODUCTION build config



Definitely, these issues were there because of bad code I wrote I guess, I should probably have written it differently in the first place. The fact is, I couldn’t realize it before it jumps at my face ! And the only way it did was to run from a bundle built for PRODUCTION.

In this project, I have been working on quite big features that needed time to be stable enough before being deployed to a common testing environment. That’s the main reason why I did not build a PROD bundle sooner…

Anyway, a lesson learned for me that I share with you today:
Build more often PROD bundles so I can be aware of these kind of issues in advance.

Hopefully you will find that post useful !

Best regards,