Gulp bundle command exit with code '1' for eslint warnings

[HuihuiWu-Microsoft]

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Developer environment

Windows

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

• browser version
• SPFx version 1.17.4
• Node.js version 16.18.0
• etc

Describe the bug / error

gulp bundle failed with exit code 1 even if there's only eslint warnings.

Steps to reproduce

1. scaffold a spfx project with 'yo @microsoft/sharepoint'
2. customize the code to include eslint error
3. run gulp bundle --ship --no-color after npm install
4. process exited with code 1 even if the eslint is only printed as warning
   

Expected behavior

The behavior should be aligned: if eslint errors are printed as warning, exit code should be 0; if eslint errors are printed as error, exit code should be 1.

[ghost]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[HuihuiWu-Microsoft]

This is related to an IcM incident that user is using Teams Toolkit to deploy SPFx but failed. The root cause is that there's eslint error in user's customized code and when user deploy with TTK, TTK will run gulp bundle but failed since the exit code is 1.

User is complaining that it shouldn't block since it's displayed as warning. It's quite misleading for customers.

[nick-pape]

@HuihuiWu-Microsoft

Interesting. So yes, by default, linter warnings are treated as build-blocking errors when running in --ship. This is generally a good practice, otherwise builds would not be blocked and lint errors would proliferate in the codebase. In other words, there's no point in running the linter if the user is going to just ignore the errors. Without the --ship flag, we do not treat linter as an error because it is highly annoying that one cannot test their code (in their inner dev loop) because of lint errors.

There's a few things the user can do here:

Best solutions:

• Fix the code such that it does not have a lint warning. Using any is error prone and should be avoided.
• Add an eslint override comment to the code so that the linter ignores the warning (// eslint-disable-next-line @typescript-eslint/no-explicit-any)

Less ideal solutions:

• Make lint warnings always be treated as build blocking errors (even without --ship).
  • Note this could be annoying during a developer's inner loop.
  • Add a file called lint.json in the config/ folder. Add the following:

    { displayAsError: true; }
    

  • Alternately, update gulpfile.js and add:

    build.lintCmd.setConfig({ displayAsError: true });
    

  • See here.

Solutions that work but are not recommended:

• Add an override to the build to ignore the error:
  • In gulpfile.js add use the build.addSuppression(); which accepts a RegEx or a string).
  • See here.
• Disable the rule in the project's .eslintrc.js config
• Disable the linter entirely (in gulpfile.js add build.lintCmd.enabled = false;)

However, I will say this is default behavior that we are not planning to change.

[ghost]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues