no-access-missing-member removed - needed for JIT

[peterdolenc]

Hi, since the update to angular 5 and codelyzer >=4.0.0 these two rules were removed from codelyzer.

no-access-missing-member,
templates-use-public

This is a big problem for everyone who uses angular 5 with JIT compiler and not AOT compiler, as it results in templates not being linted.

Considering that in many instances AOT cannot be used as it does not support all language features and angular language service is only visible in IDE (if noticed) there isn't really a solution for this problem that was not present in version < 4.0.0.

My suggestion is, of course, to add these two rules back. It would really help a lot.

[mgechev]

Let's collect some feedback.

[listepo-alterpost]

I agree with @peterdolenc

[listepo]

+1 , I think it would be good to have AOT checks as tslint rule for JIT mode(for simple editor or IDE or CI)

[wKoza]

Soon, Angular CLI will propose AOT by default for our developments. Angular Team aims at AOT compilation by default. I'm not sure that it is a good reason for adding this rules again.

[sreichi]

Soon, Angular CLI will propose AOT by default for our developments. Angular Team aims at AOT compilation by default. I'm not sure that it is a good reason for adding this rules again.

I dont think this will happen soon since they do not support 100% of the language features JIT is supporting. And if this will be really the case the rule can be removed again. But until then it would be a big help to get this rule back!

[wKoza]

Take a look at this issue angular/angular-cli#8259. Angular CLI does not use AOT (ng serve) by default, only for performance reasons; But it's the target. ng build uses AOT by default.

About this, Hansl says:

Yes and no. We have a plan to remake the build system which will allow us to keep using webpack while also splitting your application in smaller pieces. When that's in, you should see shorter rebuild times (assuming you're following our best practices).

In your case, @sreichi , I can only advise you to find workarounds in your code and to use AOT.

[peterdolenc]

At the moment JIT is the default (dev) compiler, therefore it makes sense to support template linting for it. Even if weren't default anymore (as indicated by @wKoza), I think it would still make sense to support it. I don't see why you would not support something just because it's not the default option out of the box (and at the moment it even is).

Furthermore, having these rules supported will not hurt anyone who does not want to use it. Whereas, not having it is a major downfall for all those having to use JIT.

[wKoza]

Why do you want to have the rule templates-use-public if you use JIT ?

Regarding the rule no-access-missing-member, we have some problems including class inheritance for example (#191). This is one of the reasons for its deletion.

[sreichi]

Regarding the rule no-access-missing-member, we have some problems including class inheritance for example (#191). This is one of the reasons for its deletion.

but is this really worth for its deletion? The rule set is not the list of "you must use this rules otherwise your code is shit" everyone can enable/disable every rule they want. So i really don't understand whats your point against putting it back since a lot of community members really wanna use it

[wKoza]

I understand your problem @sreichi. The rule no-access-missing-member is interresting in your case but the rule is perfidious currently ...

[ampled]

I'm running a hybrid application with a manual webpack setup with JiT for our dev server and AoT for building using the ngtools/webpack package from angular. Having this rule in place would be great for the dev server as a soft reminder.

We are using the Angular Language Service-plugin, but it has proven to be very unstable in our case (frequent crashes and takes forever to update whenever changes are made to the template or component class.) I'd love to use these rules for our JiT dev server so that it pops up as a warning with a webpack ts-lint plugin or something.

[intellix]

to reinforce the above comment. I've been trying to use the Angular Language Service every couple of months since it came out and end up disabling it same or next day due to how unstable it is. I'm still finding it to be largely unusable.

Writing in HTML and getting autocomplete for Emmet suggestions just dies and I end up disabling it each time. Dunno when it'll become usable for me really, still waiting

[mgechev]

Let's close this rule. There are a lot of upcoming changes in the Angular compiler.