Sp-dev-docs: The build failed because a task wrote output to stderr when run gulp bundle --ship

[gzhou2018]

Thank you for reporting an issue or suggesting an enhancement. We appreciate your feedback - to help the team to understand your needs, please complete the below template to ensure we have the necessary details to assist you.

_(DELETE THIS PARAGRAPH AFTER READING)_

Category

• [ ] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

For the above list, an empty checkbox is [ ] as in [SPACE]. A checked checkbox is [x] with no space between the brackets. Use the PREVIEW tab at the top right to preview the rendering before submitting your issue.

If you are planning to share a new feature request (enhancement / suggestion), please use SP Dev UserVoice at http://aka.ms/sp-dev-uservoice. (DELETE THIS PARAGRAPH AFTER READING)

_(DELETE THIS PARAGRAPH AFTER READING)_

Expected or Desired Behavior

If you are reporting a bug, please describe the expected behavior. If you are suggesting an enhancement please describe thoroughly the enhancement, how it can be achieved, and expected benefit.

_(DELETE THIS PARAGRAPH AFTER READING)_

Observed Behavior

If you are reporting a bug, please describe the behavior you expected to occur when performing the action. If you are making a suggestion, you can delete this section.

_(DELETE THIS PARAGRAPH AFTER READING)_

Steps to Reproduce

If you are reporting a bug please describe the steps to reproduce the bug in sufficient detail to allow testing. Only way to fix things properly, is to have sufficient details to reproduce it. If you are making a suggestion, you can delete this section.

_(DELETE THIS PARAGRAPH AFTER READING)_

Submission Guidelines

• All suggestions or bugs are welcome, please let us know what's on your mind.
• If you are reporting an issue around any of the documents or articles, please ensure that you have clear > reference on the specific file or URL, which should be fixed.
• If you have technical questions about the framework, we’ll be monitoring #spfx, #spfx-webparts, and > #spfx-tooling on (SharePoint StackExchange)[http://sharepoint.stackexchange.com/]. You can also > alternatively submit your question to (SharePoint Developer group)> [https://network.office.com/t5/SharePoint-Developer/bd-p/SharePointDev] at Office Network.
• Remember to include sufficient details and context.
• If you have multiple suggestions or bugs please submit them in separate bugs so we can track resolution.

_(DELETE THIS PARAGRAPH AFTER READING)_

Thanks for your contribution! Sharing is caring.

[gzhou2018]

I am following the Client web part instruction 4 and when run gulp bundle --ship .
Got error: The build failed because a task wrote output to stderr.
It seems a bug

[VesaJuvonen]

It's indeed unnecessary message, but should not cause you any issues and the web part works regardless. Is that correct?

[abhishek-raj]

@VesaJuvonen No, it doesn't break the webpart but the build process in CI/CD fails due to this message.

[CloudDesignBox]

I get the same issue but the build and package does complete fine.

[waldekmastykarz]

You can get rid of the warnings by disabling the rules mentioned in the warning in the config/tslint.json file:

{
  "$schema": "https://developer.microsoft.com/json-schemas/core-build/tslint.schema.json",
  // Display errors as warnings
  "displayAsWarning": true,
  // The TSLint task may have been configured with several custom lint rules
  // before this config file is read (for example lint rules from the tslint-microsoft-contrib
  // project). If true, this flag will deactivate any of these rules.
  "removeExistingRules": true,
  // When true, the TSLint task is configured with some default TSLint "rules.":
  "useDefaultConfigAsBase": false,
  // Since removeExistingRules=true and useDefaultConfigAsBase=false, there will be no lint rules
  // which are active, other than the list of rules below.
  "lintConfig": {
    // Opt-in to Lint rules which help to eliminate bugs in JavaScript
    "rules": {
      "class-name": false,
      "export-name": false,
      "forin": false,
      "label-position": false,
      "member-access": true,
      "no-arg": false,
      "no-console": false,
      "no-construct": false,
      "no-duplicate-case": false,
      "no-duplicate-variable": true,
      "no-eval": false,
      "no-function-expression": true,
      "no-internal-module": true,
      "no-shadowed-variable": true,
      "no-switch-case-fall-through": true,
      "no-unnecessary-semicolons": true,
      "no-unused-expression": true,
      "no-use-before-declare": true,
      "no-with-statement": true,
      "semicolon": true,
      "trailing-comma": false,
      "typedef": false,
      "typedef-whitespace": false,
      "use-named-parameter": true,
      "valid-typeof": false,
      "variable-name": false,
      "whitespace": false
    }
  }
}

[abhishek-raj]

As @waldekmastykarz suggested delete the rules or update the rules as warned by the compiler.

[octogonz]

By design, a --ship build should never have warnings. Otherwise, this is what happens:

1. Some warnings appear, but nobody fixes them. (People read the warnings, but if they aren't relevant, they don't see a need to do anything.)
2. More warnings accumulate over time.
3. Eventually, so many warnings are getting dumped into the logs that it's difficult to notice when a new warning appears. (For example, today there are 56 warnings, but yesterday there were only 54 warnings.
   Nobody memorizes these numbers.)
4. In the end, everybody always ignores new warnings and old warnings. Nobody reads them at all.

People working on the tools begin to ask: Why are we bothering to classify certain messages as warnings? With these semantics, they seem indistinguishable from ordinary log messages.

Based on this experience, we arrived at the following definitions for our tooling:

• Error: Indicates a serious problem. Appears in red. Always breaks the build.
• Warning: Indicates a possible problem. Appears in yellow. Doesn't break a developer's build, but always breaks a --ship build. For example, a pull request cannot be merged with warnings (because it requires a successful --ship build). If warnings are false alarms, then you can completely disable them (as mentioned above), but it's often better to suppress particular instances. With tslint, you suppress warnings by inserting special code comments. For general build warnings, the gulpfile.js provides a generic way to suppress any warning.
• Informational: The default for log messages. Never breaks the build. Can use colors, but will never use the special red or yellow colors.
• Verbose: Enabled via the "--verbose" flag.

[Krak86]

Just for quick win you can use --debug flag for bundling task instead of --ship until this bug will be fixed in future releases:

gulp bundle --debug
gulp package-solution --ship
The bundled file will be bigger, but at least you are not getting "The build failed because a task wrote output to stderr" error in CI/CD.

[octogonz]

@VesaJuvonen I didn't realize this happens when following an official tutorial. We should fix the tutorial and/or Yeoman generator to eliminate the warning, if that's the case.

[abhishek-raj]

@pgonzal It is happening after following the official tutorial. The two tslint flags which are in tslint.json are causing this(namely: no-duplicate-case should now be no-duplicate-switch-case and valid-typeof should be removed as it is deprecated).

[ElliotSchmelliot]

Solution from @abhishek-raj above worked for me. I agree with @pgonzal, I think Yeoman should be updated to properly generate the tslint.json file. Others using the tutorial will run into this exact same issue.

[ashishshukla1183]

Solution from @abhishek-raj above worked for me. I agree with @pgonzal, I think Yeoman should be updated to properly generate the tslint.json file. Others using the tutorial will run into this exact same issue.
It didn't worked for me. I upgraded from 1.4.1 to 1.6. Even same issue comes when I upgrade to 1.5.1. Build completes successfully, but ship has a problem. Any suggestions how to fix the issue?

[octogonz]

@patmill FYI

[ashishshukla1183]

Actually that was mistake on my part. I just took the latest tslint from a fresh 1.6 project, added file by file, and now the error is gone. not sure yet which rule was causing the issue as i still have a bunch of warnings.

[bigpix2000]

@VesaJuvonen I am running into an issue where AzureDevOps Pipeline task fails when I do gulp bundle --ship (works fine without --ship) What this post is telling me is that tslint needs to be essentially all disabled in order to suppress the warnings and, in turn, allow it to proceed … or am I missing something? I am using the latest framework but, and this is important, I am targeting 1.4.0 because this is going to SP 2019 on prem. I see a note from @ashishshukla1183 that a file from 1.6 solves things and perhaps I can go to a 1.7 project and bring that over as a fix as well? Hoping you will see this soon with some guidance at least as we are blocked on CICD until then. (also, we might want to make an updated video of the ALM to include or one separate doing the CI CD thing in the docs but with powershell instead of the CLI ;-) or maybe I can do one :p) Anyway thanks in advance!

[bigpix2000]

Update on this end, there is a very recent post from @estruyf that address how to deal with the issue! I imagine at some point the fix may be something we want to see in a future version of the framework or at least documentation in the area that discusses CI CD (that one needs a Powershell on prem version to it anyway) … Here is the link for those visiting this issue: https://www.eliostruyf.com/how-to-let-the-warnings-not-fail-the-sharepoint-framework-build-process/

[kiransripada]

This solution works like a charm for me

[bigpix2000]

To be clear, the issue is particularly noticed when deploying to SP 2019 On Prem

[msft-github-bot]

This issue is being closed as part of an issue list cleanup project. Issues with no activity in the past 6 months that aren't tracked by engineering as bugs were closed as part of this inititive. If this is still an issue, please follow the steps outlined to re-open the issue.