Skip to content

Lint errors shown as syntax errors in editors #10727

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

Closed
cyrilletuzi opened this issue May 8, 2018 · 4 comments
Closed

Lint errors shown as syntax errors in editors #10727

cyrilletuzi opened this issue May 8, 2018 · 4 comments

Comments

@cyrilletuzi
Copy link
Contributor

cyrilletuzi commented May 8, 2018

Versions

cli v6.0.0

Repro steps

  • ng new helloworld
  • In an editor like Visual Studio Code, do something not respecting lint rules (like an expression not terminated by a semicolon)

Observed behavior

An error, similar to a syntax error, is displayed (in red).

Desired behavior

Should display a warning (in green).

Mention any other details that might be useful (optional)

This issue is here for a long time, and has already been discussed in angular/devkit#269.

Again, I'm animating a lot of Angular courses, and it's really disturbing for new comers. And to back up my opinion, Vue.js is configuring lint errors as warnings, as I advocated.

Solution firstly proposed in PR angular/devkit#463, but ignored for a long time, redone in angular/devkit#867 for CLI v6. Now that 6.0 is released, would be nice to be tracked for 6.1. It's keeping the current behavior for ng lint, and change to warnings only in the editor.

@cyrilletuzi cyrilletuzi changed the title Editors show lint errors as syntax errors Lint errors shown as syntax errors in editors May 8, 2018
@delasteve
Copy link
Contributor

I think this is something that is out of scope of the CLI. The CLI shouldn't dictate how the editor acts. That default behavior should be up to the editor.

A question that should answered is, "where is the line drawn for what the CLI says the editor behavior should be?"

This request (and PR: angular/devkit#867) opens the CLI up to having to maintain configurations per editor, and there are many editors. It would also require updates to the schematics should any editor change it's behavior.

As a side note, personally, I like errors as actual errors, not warnings.

@cyrilletuzi
Copy link
Contributor Author

The solution proposed by the PR is about editor config because the problem happens only in the editor. I'm not sure about your reasoning: if we go your way, we could say: it's up to tslint to manage its default settings, etc.

The role of the CLI is to have a ready-to-use project, and the current default configuration is very disturbing for beginners (as an Angular teacher, I see a lot of students being stuck on lint errors). And for everyone, it does not feel normal and intuitive that lint errors appear the same way as syntax errors (as the last ones will really produce errors, while lint problems won't).

As a reminder, lint errors as warnings was the initial default behavior of the CLI. It changed not on purpose, but just because tslint changed its default configuration in v5. So this could be considered as a bug.

But I agree a much better solution would be to set defaultSeverity to warning in tslint.json (like Vue.js does) and that ng lint overrides this setting for its need (or even better, that ng lint fails on warnings and not just errors).

I would be happy to go that way, but I don't know if the CLI team is OK for it.

@cyrilletuzi
Copy link
Contributor Author

Closing, the CLI team prefers to keep the current behavior.

@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 Sep 8, 2019
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

3 participants