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

style(linting): enable 'noImplicitThis' compiler option #2103

Merged
merged 1 commit into from
Nov 9, 2016

Conversation

tetsuharuohzeki
Copy link
Contributor

@tetsuharuohzeki tetsuharuohzeki commented Nov 4, 2016

Description:

  • This intent to make this type explicitly.
    • This would make our codes more type safe with a compiler enforcement.
    • This makes our API documentation better.
  • I think this would not be a breaking change by these reasons:
    • There are no problem if we pass the function which does not has this specifying.
    • There are no problem if we pass the function which has this: any or this.
      • This case is valid with the actual behavior.
    • If we pass the function which has invalid this type
      then, basically, its code would be wrong.

Related issue (if exists):

@coveralls
Copy link

Coverage Status

Coverage remained the same at 97.593% when pulling 1074cb7 on saneyuki:noImplicitThis into 39214f2 on ReactiveX:master.

@jayphelps
Copy link
Member

I don't believe this and #2104 are features (i.e. publicly accessible API/behavior additions). They are more like a refactor. Anyone else have thoughts?

@kwonoj
Copy link
Member

kwonoj commented Nov 4, 2016

@jayphelps I agree, as these change should not impact public api surface.

for this one, as shared in original issue I'm not in great favor of this changes while I would not suggest to block check in completely. My experience with this flag usually caused unnecessary pain point for some tricky cases

@david-driscoll
Copy link
Member

@kwonoj do you have specific cases? With the new this syntax I've not had any issues. I've had lots of problems with tslint in the past though.

@kwonoj
Copy link
Member

kwonoj commented Nov 5, 2016

@david-driscoll sorry, it was bit while and I don't have examples for now.

@tetsuharuohzeki
Copy link
Contributor Author

@jayphelps

I don't believe this and #2104 are features (i.e. publicly accessible API/behavior additions). They are more like a refactor. Anyone else have thoughts?

Okay. I'll change to style(linting).

@tetsuharuohzeki tetsuharuohzeki changed the title feat(TypeScript): enable 'noImplicitThis' compiler option style(linting): enable 'noImplicitThis' compiler option Nov 7, 2016
@coveralls
Copy link

Coverage Status

Coverage remained the same at 97.595% when pulling becad1c on saneyuki:noImplicitThis into bf3c043 on ReactiveX:master.

@jayphelps
Copy link
Member

LGTM

@jayphelps jayphelps merged commit 4fc55b1 into ReactiveX:master Nov 9, 2016
@tetsuharuohzeki tetsuharuohzeki deleted the noImplicitThis branch November 10, 2016 05:06
@lock
Copy link

lock bot commented Jun 6, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Jun 6, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants