Skip to content
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

ng lint succeeds when tslint fails, and other default linting misconfiguration (vscode) #16231

Closed
1 of 15 tasks
Masterxilo opened this issue Nov 19, 2019 · 9 comments
Closed
1 of 15 tasks

Comments

@Masterxilo
Copy link

🐞 Bug report

Command (mark with an x)

  • new
  • build
  • serve
  • test
  • e2e
  • generate
  • add
  • update
  • lint
  • xi18n
  • run
  • config
  • help
  • version
  • doc

Is this a regression?

No, this never worked AFAIK.

Description

tslint and ng lint should behave the same.

In general, ng build and ng serve should fail when code that tslint shall consider as {"severity": "error"} is encountered.

I lost 3 hours first isolating a bug caused by a shadowed variable, then trying to make my build always fail and my IDE report "no-shadowed-variable" as an error.

After I put the line

"no-shadowed-variable": {"severity": "error"}

in the ./tsconfig.json file, all my tools should recognize and report this error always.

Currently they don't. ng lint is one of them

🔬 Minimal Reproduction


ng new tslint-errors-ng-vscode

Then append to app.component.ts the following


function f(key: string) {
    const o = {hello: 0};
    Object.keys(o).forEach((key: string) => {console.log(key)});
}

f("world")

This code demonstrates shadowing. Does it do what we want? We should probably have used a different variable name.
Let's assume we had a bug caused by shadowing.
Now we want to make sure that never happens again, so we want the build to fail if we ever rely on shadowing anywhere.

So we put in tslint.json under rules:

"no-shadowed-variable": {"severity": "error"}

But damn it:
Our IDE still shows it as a warning:
image
aha, the vscode team messed up: microsoft/vscode-typescript-tslint-plugin#122
so we configure in settings json "tslint.alwaysShowRuleFailuresAsWarnings": false

F*** now everything is an error:
image

Aha, the angular team messed up: The didn't put any "defaultSeverity" in ./tslint.json so let's do that:

"defaultSeverity": "warning"

After restarting the IDE (because we live in the fantastic time where some changes have immediate effect and some require a restart and no one know which require a restart...) it behaves properly
image
Now lets see the CLI:

tslint --project . --quiet

properly reports only the ERRORs
image

ng lint

detects the error, but happily reports that "All files pass linting.". Clearly a BUG.
image

ng serve succeeds - arguably it should treat linting errors just as much as errors as typechecking errors!

ng build succeeds - yay, "errors" in tslint.json officially means nothing to angular :(

🔥 Exception or Error


All files pass linting.

When there is a linting ERROR.

🌍 Your Environment



     _                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/
    

Angular CLI: 8.3.19
Node: 11.13.0
OS: win32 x64
Angular: 8.2.14
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router

Package                            Version
------------------------------------------------------------
@angular-devkit/architect          0.803.19
@angular-devkit/build-angular      0.803.19
@angular-devkit/build-optimizer    0.803.19
@angular-devkit/build-webpack      0.803.19
@angular-devkit/core               8.3.19
@angular-devkit/schematics         8.3.19
@angular/cdk                       8.2.3
@angular/cli                       8.3.19
@angular/flex-layout               8.0.0-beta.27
@angular/material                  8.2.3
@angular/material-moment-adapter   8.2.3
@ngtools/webpack                   8.3.19
@schematics/angular                8.3.19
@schematics/update                 0.803.19
rxjs                               6.5.2
typescript                         3.5.3
webpack                            4.39.2

Anything else relevant?
Related Issues:

@clydin
Copy link
Member

clydin commented Nov 19, 2019

The workspace shown above has two projects:

  • tslint-errors-ng-vscode -- this is failing with the variable shadow error
  • tslint-errors-ng-vscode-e2e -- this is passing

The standalone E2E project is an artifact from an earlier version of the CLI and a project generated by 8.3.19 will not have a standalone E2E project. The E2E testing has been incorporated into the main project.

@alan-agius4
Copy link
Collaborator

alan-agius4 commented Nov 19, 2019

With regards to your point that lint errors should fail ng serve and ng build, IMHO Is not desirable as during development, a developer will usually make “style” related errors especially during debugging and experimenting and those should be totally acceptable and failing a build for lint/style related errors would be a bad developer experience apart from reducing developer productivity as they will need to go back and forth to fix style related errors rather than focusing on their task.

IMO, Lint should be used as a precommit step or/and as a CI check which if that fails will make the PR unmergable.

@Masterxilo
Copy link
Author

I kindly disagree. tslint has severities warning and error. If desired, a developer or automated tooling could set the linting severities to warning instead of error during development. But at least ng lint should fail when there are errors.

Otherwise ng lint is not useful as an automateable cli tool, there would be no place in having it integrated into ng in the firat place.

Linting errors should be strictly distinguished from linting warnings

@Masterxilo
Copy link
Author

In an effort to make the most out of tooling and automated best practice enforcement, many good developers treat all warnings as error and only very carefully ignore them

@alan-agius4
Copy link
Collaborator

But at least ng lint should fail when there are errors.

It does, ng lint will exit with a non zero error code when there is a lint error.

Linting errors should be strictly distinguished from linting warnings

When there are no errors, ng lint is not exited with a non zero error code but will when there is a lint error.

@clydin
Copy link
Member

clydin commented Nov 20, 2019

As mentioned above, the lint command will run against each project within the workspace and provide a separate output for each project. In the output provided in the screenshot, the tslint-errors-ng-vscode project is indeed failing and being reported as such. The second (and last) project, however, is succeeding hence the line indicating the files passed. The error code for the command will also represent the total success or failure of the command for all projects checked. The error code is useful as well if it is indeed desired to not build if lint fails (ng lint && ng build).

@alan-agius4
Copy link
Collaborator

Closing as per above, as it doesn't seem to be a bug here.

@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Dec 29, 2019
@IgorMinar
Copy link
Contributor

@Masterxilo I just wanted to follow up on your original issue description and point out that it reflects a lot of frustration and is borderline aggressive.

This might not have been your intention, but I wanted to let you know that that's how it was received. In the future please try to stay away from using profanity, verbal attacks, or negative comments directed at individuals or groups of people.

The issue tracker is a place for collection of factual information. Your messages are read by many people, some of which might feel negatively affected by your choice of words, and in return might be less willing to help you with your issue.

Lastly, please keep in mind that just as many of our other communication channels, the GitHub issue tracker is governed by our code of conduct policy: https://github.com/angular/code-of-conduct

Thanks for understanding!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants