Wrong Error warnings for Unused patched operator in ./rxjs.imports.ts
See original GitHub issueHello,
first I want to say thank you for your really good work here. 👍
So now to my problem:
I am using the rxjs-add rule like this:
"rxjs-add": {
"options": [
{
"allowElsewhere": false,
"allowUnused": false,
"file": "./src/app/rxjs-operators.imports.ts"
}
],
"severity": "error"
},
So I use the approach to have all rxjs operators in on central file and nowhere else it is allowed to have them and don’t have unused imports for the rxjs operators in the central rxjs operator import file.
That worked fine I just got the same error that was mentioned here: https://github.com/cartant/rxjs-tslint-rules/issues/5 I could fix that, but now I am getting linting errors for Unused patched operator although they are for sure used in my project.
I think this problem is related to the stuff that it is an angular project created with angular-cli and calling ng lint and that run’s tslint three times (like you explained it):
- first, with application files from
src/
; - then with the test files from
src/
; - and, finally, with files from
e2e/
.
So I think because not all application files are there for the second and third run I get the errors with the Unused patched operators.
For now, my only solution is to use "allowUnused": true
.
Do you have an idea or hint how I could fix this problem?
Issue Analytics
- State:
- Created 6 years ago
- Comments:21 (10 by maintainers)
Top GitHub Comments
I’ve had a quick look at this and I’ve added some notes to the README.md.
When using the
file
option, all files in the program - not just the specs - are walked to determine what is unused. So if unused errors are effected, there must be operators in files that are not imported into tests. The simplest way to solve the problem would be to import them into a test - even if they are not actually tested. Or, they could be added tosrc/tsconfig.spec.json
- but that might be more tedious to maintain.Closing this, but feel free to re-open if there are further problems. Happy to continue the conversation without re-opening, too.
@kamok No worries. I appreciate your reading through the issues to find one related to your problem, but I think I speak for most maintainers in recommending that instead of commenting on a closed issue, a new issue should be opened with references to any relevant/related issues. As you can see from your resolution, it was not the same issue. Anyway, glad to hear that you have it working.