Codelyzer: Drop rules which produce warnings that are supposed to be compile-time errors

[mgechev]

Drop:

• templates-use-public
• no-access-missing-member
• invoke-injectable

[MarkPieszak]

templates-use-public is being dropped?
Couldn't get that one working actually :(

[mgechev]

What problem do you have with it?

[MarkPieszak]

It may of been the project I was working with (it had a boat-load of strange issues (hidden characters driving TSLint crazy I'm guessing), let me double check on a normal one!

[WiseBird]

These rules are very helpful when moving existing app to AOT compilation.

[mgechev]

There are also useful in AngularJS applications using ng-metadata. I will not drop them in near future.

[elvirdolic]

Can we disable these rules until this gets in?

[Vaelor]

Why are these being dropped? Couldn't find why, especially templates-use-public?

[wKoza]

Because the Angular Language Service already checks that

[listepo-alterpost]

@wKoza ng lint will output errors? I think not. I think these rules are needed

[wKoza]

No, of course. Codelyzer delegates this task to the compiler (with AOT mode) => ng build --prod

[maxrango]

I really don't understand this choice.
I use ng serve without the --aot flag because I want my dev environment to be as fast as possible and JIT compilation is made to achieve this purpose.
During development I also want to be informed as soon as possible if I'm writing code that won't work in production, when I will run ng build --prod. I don't want to find it out once I think I'm done but I'm actually not because I have to run ng serve --aot and then refactor the code I thought would work.
Am I missing something? I think this is a quite common use case.

[wKoza]

Yes, it's a common use case but as I already said, the Angular Language Service checks that.
Check if you have this dependency into your package.json:

"@angular/language-service": "X.X.X"

You have to see an error in your template if you use a private member.

[maxrango]

@wKoza Even though this is a fix to my problem, I do not fully agree with this approach:

1. This is a visual extension to commonly used IDEs. It means that some of the editors will not be supported / someone could choose not to install the extension => not scalable.
2. The VSCode plugin is super slow, plus if I use external templates I need to edit the html in order for the extension to detect errors such as templates-use-public (even though the mistake was made in the .ts. file) => not reliable.
3. I can't find a way to integrate these errors in my pre-push step, given it's all about the editor and not about the linter. Everything will work fine if I check formatting, linting and run ng test.
   The build will fail only in the final step when the compilation is done => time consuming.

[wKoza]

1. VSC and Webstorm both implement this feature.
2. You should also see errors in your error console (with Webstorm, I can see it on my Typescript error tab)
3. I'm agree, It takes time but you can delegate this task to your CI for instance.

[maxrango]

1. I know. Luckily for me, I use VSCode. Not everyone does though.
2. I don't unless I edit the html file. Unluckily for me, I use VSCode.
3. That's my point. I should not use the CI for this. Everything should fail fast. This is something I want to know as I type, at most before committing/pushing. I don't want to find it out when I already implemented everything, pushed it to master and switched to another task.

[skrzepij]

And there is still a problem with data types.
If we use in html template some parameter (as object property) which is not valid with assigned object type, then error occurs only when we make production build with AOT.
For example:
TS:

data: { name: string, code: number }

HTML:

<div>{{ data.id }}</div>

It's quite confusing.