New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The build failed because a task wrote output to stderr when run gulp bundle --ship #2131

Open
gzhou2018 opened this Issue Jun 27, 2018 · 14 comments

Comments

Projects
None yet
9 participants
@gzhou2018
Copy link

gzhou2018 commented Jun 27, 2018

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
  • 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

This comment has been minimized.

Copy link

gzhou2018 commented Jun 27, 2018

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

image

@VesaJuvonen

This comment has been minimized.

Copy link
Contributor

VesaJuvonen commented Jul 2, 2018

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

@abhishek-raj

This comment has been minimized.

Copy link

abhishek-raj commented Jul 5, 2018

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

@CloudDesignBox

This comment has been minimized.

Copy link
Contributor

CloudDesignBox commented Jul 5, 2018

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

@waldekmastykarz

This comment has been minimized.

Copy link
Member

waldekmastykarz commented Jul 6, 2018

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

This comment has been minimized.

Copy link

abhishek-raj commented Jul 18, 2018

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

@pgonzal

This comment has been minimized.

Copy link

pgonzal commented Aug 9, 2018

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

This comment has been minimized.

Copy link

Krak86 commented Aug 24, 2018

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.

@pgonzal

This comment has been minimized.

Copy link

pgonzal commented Aug 24, 2018

@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

This comment has been minimized.

Copy link

abhishek-raj commented Aug 24, 2018

@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

This comment has been minimized.

Copy link

ElliotSchmelliot commented Sep 14, 2018

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

This comment has been minimized.

Copy link

ashishshukla1183 commented Oct 25, 2018

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?

@pgonzal

This comment has been minimized.

Copy link

pgonzal commented Oct 25, 2018

@patmill FYI

@ashishshukla1183

This comment has been minimized.

Copy link

ashishshukla1183 commented Oct 25, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment