Something that is giving me some trouble for a long time is that the SharePoint Framework build process treads warnings as errors in production builds (when the –ship flag is present).
Let’s start by giving some background information. During bundling/packaging of your SharePoint Framework solution, you could see two types of messages:
- Warnings
- Errors
When running a DEBUG build, both messages are not causing the process to fail by a stderr (or standard error). Only during a PRODUCTION build, you would get the following output:
Important is the above screenshot are the last two lines. In production builds, it returns an error to let the process know it failed. For errors this is, of course, necessary behavior, but what if you only have warnings?
Even when there are only warnings, it will return a stderr error and let the process fail. Although these are “just” warnings, for the production build process they are seen as errors.
This might be an issue in your automated build/release pipelines. For instance, when you automatically bundle and package your solution on Azure DevOps, there is no way to tell that it should continue when warnings occur. The only option you have is to continue on error.
Enabling the continue on error option might give you more troubles when “real” coding errors occur.
In my case, I want to always have the latest version on my DEV environment even when there are warnings. These warnings need to be solved once the pipeline runs for any other type of environment. That way, I am always able to try out my solution, without fixing the warnings and running the build pipeline again.
Info: some of these warnings can also be suppressed like the one which is by default in place to suppress the warning for the CSS class name ‘ms-Grid’ as it is not created as camelCase. If you have warnings which will always occur and can be ignored, it is best to suppress them the same way with the build.addSuppression(string or regexp) function.
Why are warnings treated as errors?
The reason for this is the following lines in the build process initialization:
In the SharePoint build process, it defines that whenever you use the production or ship flag, the shouldWarningsFailBuild property is set to true.
Overwriting the shouldWarningsFailBuild value will not work
The shouldWarningsFailBuild property is available for you to edit in the build configuration in the gulp file. Unfortunately, the build initialization will overwrite whatever you define. In the following screenshot you can see this happening:
Extending the build process
In order to be able to set the property so that you are in control, is by extending the SharePoint Framework build process. Luckily it is not so hard to achieve.
Here is the way you can achieve it:
With the following code in place, you are in control whenever you want to treat warnings as just warnings by using the –warnoff flag.
With this warnoff flag in place, I can now specify in my DEV build pipeline to that warnings can be ignored, but for real production builds, they are treated as errors.
I hope this helps you to gain some control over what you try to achieve in your automated builds.