Lint on build + serve

[diminutivesloop]

Currently ng lint can only be run as a stand-alone command. This limits its usefulness as developers have to remember to manually run it before committing or install a linting package for their editor. Lint rules are most effective when violating them results in build failure. This makes failure obvious to developers regardless of their editor setup or workflow. While it is currently possible to accomplish this by chaining ng lint and ng build in npm scripts, this solution is not compatible with watcher tasks such as ng serve.

To fix this I recommend adding a flag to the ng serve and ng build commands that automatically runs ng lint before each build and causes a build failure on any linter rule violation.

[ghost]

At least for me, the lint command is fired in my CI process. It's not possible to merge a branch whose CI is failing. Apart from that, I really don't want the lint to slow down the already very slow build or serve commands. (lint takes forever on large projects)

Summed up, I don't only find this suggestion unnecessary, but also very disturbing. At least if this would be the default behaviour.

[filipesilva]

We actually have tslint running on ng test cycles at the moment.

I'm not too sure that I'd want linting running on all rebuilds though... it'd slow them down somewhat, which I think is suboptimal but maybe not everyone agrees on that. I'll label it as a discussion.

[diminutivesloop]

I agree it shouldn’t be on by default. My suggestion is only that an option be added to enable linting on auto-rebuid.

[fbobbio]

Hello there.

Is there in the roadmap (or currently) a way to configure our own commands as the npm one's for the ng-cli?

[filipesilva]

@fbobbio please open a new issue instead of asking questions on unrelated issues.

[lfv89]

I totally agree with @diminutivesloop, an option for ng serve would be the best of both worlds. A tight feedback cycle is always better IMHO. I would gladly jump into this if you think its a useful feature @filipesilva.

[seeruk]

Just to also add to this, I've seen some other Angular 2 / Webpack boilerplates have the linting results be shown in the browser console, that is extremely handy too (along with any compilation errors).

[DomenicRoti]

I'd also be very interested in this - though for now I'll see if I can mimic what @christiandreher is doing.

[filipesilva]

Alright, I see a fair amount of interest in it so I'll tag it for work instead of just discussion. It's not a high prio though.

[russiann]

Totally agree! 👍

[eilensm]

I'm running beta.24 of the cli and it seems to me, that ng test is currently NOT running tslint automatically (only if I pass --lint), whereas an earlier comment stated that it would do. Is this correct or am I missing sth.?
If I am correct and it is currently disabled, is there a way to enable it per default?

[tarlepp]

Hmm I also noticed that running ng test --lint doesn't give same lint errors as npm run lint - is there a reason for this?

[trickpattyFH20]

I noticed that in #4114 , the --lint option was removed from ng test.
Would the team still consider a PR for this issue, #2551 , that would add a --lint option to ng build/serve ? @filipesilva

[kuncevic]

@tarlepp I guess that is why #4114 / 55224a1

[filipesilva]

Heya, I have bad news. We don't intend to have it on build/serve for the same reasons as described in #4114.

[sv2dev]

What about incremental linting?
I built this within a starter. You only have to run a lint on startup and hold all errors in-memory. Then you update that map only for changed files and output all errors.
It's blazing fast.

[abdel-ships-it]

@filipesilva I understand why you would remove the --lint flag in the context of unit tests, it's a trap. But in the case of a serve there are obviously people that would find this feature useful (including my self)

Beside the fact people simply want this, the reasons listed in #4114 are not as relevant to the serve. I think having the option there and disabling it by default would be the best of both worlds.

[JakeSummers]

I would really appreciate having this built into ng serve so that my teammates see this when running. Am just exploring this cli and I think this might be a deal breaker for me.

[IntegerMan]

Either NG Serve integration or a way of running ng lint with a watch would be useful to my workflow. I work with pretty strict expanded lint rulesets and while WebStorm does give you context highlighting on TSLint violations when you are inside of a file with violations, it does not give immediate feedback for a solution-level analysis unless you explicitly run TSLint. This means that you may be running development via ng serve and not realize that there are linting errors and must then remember to manually lint your code, which slows down the process. Sure, the CI process catches the error, but you hate to see folks breaking the build when tooling like ng serve could tell them in advance that they have linting issues, or a separate watching process could be set up for ng lint, which seems like it might be a better solution and one that could be easier to implement..

[sv2dev]

@IntegerMan if your concern is having linting errors in CI, you could give husky a try.

[IntegerMan]

Hey, thanks @svi3c I'd not heard of that. That just might meet my needs. I'd rather get that feedback from a tool in real-time via serve or a watching lint, but this would meet that concern. I'll try it out over the weekend.

[phm200]

@IntegerMan my team is working through the exact same issue around ng lint, in that we really want to have tslint running automatically on changes. Our CI process catches the problems if forget to run ng lint ourselves, but would be a big convenience to us have a watch option.

[IntegerMan]

I think we ultimately just need some more hooks into the serve process in general, or a way of having a watching build that can chain into other steps.

We just finished a fairly long project in Angular 4 CLI where we had an MVC page in a production product that hosted the Angular app and passed in information to it via some custom things on a namespace inside of Window. This MVC page also managed script and style includes. Since this was a decently complex thing, we had to effectively ignore index.html inside of the Angular app during development, and as a post:build step we'd copy over the script files (disabling the random filename generation that Angular does). It was a bit of an unusual setup, to be fair. The problem is that since we relied on a post:build step to copy the files over, we couldn't even do a watch to trigger this as the watch would just re-run the actual build. Since we can't get files out of ng serve, that effectively meant that we had to manually build every time, which is a lousy way of building out a product, but we were always testing it inside of an integrated context, which helped catch other issues.

Angular 6's build improvements will fix some of these performance headaches, but giving us more flexibility and eventing during the build or serve process would have been nice.

[angular-automatic-lock-bot]

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.}