I'm getting a false positive when using angular2localization translate pipe. The pipe requires some parameters like:
<h1>{{ 'toolbar.title' | translate:lang }}</h1>
but the lang parameter is causing the following error:
src/client/app/shared/toolbar/toolbar.component.html[1, 36]: The property "lang" that you're trying to access does not exist in the class declaration.
Using codelyzer 2.0.0-beta.3
It seems lang is not defined, and codelyzer is correct in this case. I saw a couple of examples of the translate pipe where it uses a missing lang property, which is later passed to a method of a service that as default argument uses the default locale. I didn't find a definition of a local view property through setting a property of the current context.
Does your code work with AoT compilation? If it does, what starter do you use?
Let me know if my findings are missig something.
Yes, the code is working with AoT compilation. The translations are working fine both with Aot and JIT compilations.
I don't think is an issue os the lang not being defined since the angular2localization explicitly defines it. See https://github.com/robisim74/angular2localization/blob/master/doc/spec.md#2.
The translation won't even work if lang is omitted when using parameters, e.g.:
<h1>{{ 'toolbar.title' | translate:lang:{version:2} }}</h1>
I've been looking into it and it seems that this issues is related with issue #191
My component is extending angular2localization Locale wich defines lang, so langis definitely defined.
@emilio-simoes thanks for the insight. I'll work on support for extended classes in the next release.
This is still an issue in Codelyzer 3.0.0.
Can confirm, please reopen the issue.
https://github.com/mgechev/codelyzer/issues/297#issuecomment-296857427
If you need type checking (support for inheritance, etc.) you should switch back to the beta version. Another problem here is that the linting gets very slow.
Keeping the performance in mind, I'm not sure if we should perform a flat or deep analysis of the application.
Most helpful comment
@emilio-simoes thanks for the insight. I'll work on support for extended classes in the next release.