Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rxjs-add false positive when type is not specified explicitly #13

Closed
balassy opened this issue Oct 18, 2017 · 4 comments
Closed

rxjs-add false positive when type is not specified explicitly #13

balassy opened this issue Oct 18, 2017 · 4 comments

Comments

@balassy
Copy link

balassy commented Oct 18, 2017

I have the following function in an Angular 4 service class:

public get(url: string): Promise<Response> {
  return this._http.get(url).toPromise();
}

Note, that the get function returns an Observable, but this type name is not appearing in the code explicitly.
The .toPromise() function of Observable is imported in rxjs.imports.ts like this:

import 'rxjs/add/operator/toPromise';

And I have the following rule in tslint.json:

"rxjs-add": {
  "options": [{
      "file": "./src/rxjs.imports.ts"
  }],
  "severity": "error"
}

This triggers the following error when running tslint, which seems to be a false alarm:

ERROR: (rxjs-add) C:/Git/MyProject/src/rxjs.imports.ts[4, 1]: 
Unused patched operator in ./src/rxjs.imports.ts: toPromise

Thank you for creating and maintaining this library, Nicholas!

György

@cartant
Copy link
Owner

cartant commented Oct 18, 2017

First question: are you using TSLint's no-unused-variable rule? That rule has given me major problems in the past. See #4.

@balassy
Copy link
Author

balassy commented Oct 18, 2017

Yes, I am using tslint:all ruleset, which turns on no-unused-variable by default. I've checked now, and turning it off fixes this problem.
Thank you!

@cartant
Copy link
Owner

cartant commented Oct 18, 2017

Yeah, the no-unused-variable rule misbehaves badly. It's had problems that have been 'fixed' before, but it's still broken in a way that affects other rules. It's a pity, as it's a useful rule. However, it's wasted so much of my time on previous occasions and is difficult to debug, so I just switch if off.

@cartant cartant closed this as completed Oct 18, 2017
@balassy
Copy link
Author

balassy commented Oct 18, 2017

All right, thank you very much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants