You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 25, 2021. It is now read-only.
I'm working on a tool called codelyzer. It exports a few tslint rules which are Angular specific. Internally the tool resolves the templates and styles of Angular components, parses them and performs analysis over them.
Later, based on this analysis the tool produces diagnostics which not always should be reported in the source file which was initially analyzed by tslint, i.e. tslint may initially perform analysis over app.component.ts but the diagnostics can be reported to app.component.html. This happens by providing app.component.html as source file to the template visitor which extends RuleWalker internally.
Actual behavior
Currently the produced replacements which should be applied to templates or styles are applied to the TypeScript file of the component which references them.
Expected behavior
The fixes should be applied to the files where the failure is reported, i.e. if the failure is reported for app.component.html and the value of failure.getFileName() === 'app.component.html' then the fix should be applied to app.component.html.
Fix
The fix will require change in linter.ts, something like:
Fixpalantir#2392
The spec that I added extends the `Linter` in order to test the extra
method I added. Since tslint doesn't have any rules which apply fixes in
a file different from the one which is currently being linted, I didn't
come up with additional tests.
Fixpalantir#2392
The spec that I added extends the `Linter` in order to test the extra
method I added. Since tslint doesn't have any rules which apply fixes in
a file different from the one which is currently being linted, I didn't
come up with additional tests.
mgechev
added a commit
to mgechev/tslint
that referenced
this issue
Apr 1, 2017
Fixpalantir#2392
The spec that I added extends the `Linter` in order to test the extra
method I added. Since tslint doesn't have any rules which apply fixes in
a file different from the one which is currently being linted, I didn't
come up with additional tests.
Fix#2392
The spec that I added extends the `Linter` in order to test the extra
method I added. Since tslint doesn't have any rules which apply fixes in
a file different from the one which is currently being linted, I didn't
come up with additional tests.
Introduction
I'm working on a tool called codelyzer. It exports a few tslint rules which are Angular specific. Internally the tool resolves the templates and styles of Angular components, parses them and performs analysis over them.
Later, based on this analysis the tool produces diagnostics which not always should be reported in the source file which was initially analyzed by tslint, i.e. tslint may initially perform analysis over
app.component.ts
but the diagnostics can be reported toapp.component.html
. This happens by providingapp.component.html
as source file to the template visitor which extendsRuleWalker
internally.Actual behavior
Currently the produced replacements which should be applied to templates or styles are applied to the TypeScript file of the component which references them.
Expected behavior
The fixes should be applied to the files where the failure is reported, i.e. if the failure is reported for
app.component.html
and the value offailure.getFileName() === 'app.component.html'
then the fix should be applied toapp.component.html
.Fix
The fix will require change in
linter.ts
, something like:Let me know what you think. Would love to open a PR.
The final goal is to provide automatic migration for the deprecations introduced by Angular 4.
The change will not introduce any breaking changes and will not change the current behavior.
The text was updated successfully, but these errors were encountered: