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

Allow context type annotation on getters/setters #9641

Merged

Conversation

matt-tingen
Copy link
Contributor

Q                       A
Fixed Issues? Fixes #8069
Patch: Bug Fix? Yes
Major: Breaking Change? No
Minor: New Feature? No
Tests Added + Pass? Yes
Documentation PR Link N/A
Any Dependency Changes? No
License MIT

Typescript allows adding type annotations to the context (this) for functions, including getters and setters. Presently, the parser errors out when such an annotation is present on a getter or setter because it expects exactly 0 or 1 parameter, respectively.

This change causes the parser to allow an extra first parameter to getters and setters when using the typescript plugin and the parameter's name is this.

babel-plugin-transform-typescript already strips the this: ... annotation from functions, including getters and setters, but I added a test to verify this in addition to the parser test.

@babel-bot
Copy link
Collaborator

babel-bot commented Mar 5, 2019

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/10410/

@matt-tingen matt-tingen force-pushed the 8069-typescript-getter-setter-this branch from b8adb6a to 238598c Compare March 6, 2019 00:43
@danez danez added pkg: parser area: typescript PR: Spec Compliance 👓 A type of pull request used for our changelog categories labels Mar 6, 2019
Copy link
Member

@danez danez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you very much.

@nicolo-ribaudo nicolo-ribaudo self-requested a review March 6, 2019 11:21
method.params[0].type === "Identifier" &&
method.params[0].name === "this"
) {
this.expectPlugin("typescript");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When the first parameter is this the new implementation doesn't check the parameters count because the } else if (method.params.length !== paramCount) { branch is skipped: (EDIT: I was wrong)

//get prop(this: {}, foo, bar) {}

If we parsed this as a function parameter, then this plugin is already enabled (no need to assert). I would prefer to have as few as possible TypeScript-specific logic in the parser/* files. WDYT about extractions method.kind === "get" ? 0 : 1 to a new getAccessorsExpectedParamCount(method) function and overwrite it in the typescript plugin?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

method.params.length === paramCount + 1 wouldn't be true in that case I guess?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh right 🤦‍♂️

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nicolo-ribaudo I have pushed a change for getGetterSetterExpectedParamCount. Thanks for suggesting the separation. I hadn't noticed I had the first usage of this.expectPlugin("typescript").

At first, it felt a little odd that the error messages directly reference the required number of params despite that number being abstracted away. I considered extracting a checkGetterSetterExpectedParamCount method instead, but didn't find a good way to do so without duplicating logic in the TypeScript plugin. However, I found that there's less of a dissonance if I look at it as the error messages being based on target language and getGetterSetterExpectedParamCount being based on the source language, so I'm on board now 😄

@nicolo-ribaudo nicolo-ribaudo merged commit e53be4b into babel:master Mar 6, 2019
@nicolo-ribaudo
Copy link
Member

Thanks!

@matt-tingen
Copy link
Contributor Author

My pleasure! Thanks for the quick reviews!

@matt-tingen matt-tingen deleted the 8069-typescript-getter-setter-this branch March 6, 2019 21:56
matt-tingen added a commit to matt-tingen/babel that referenced this pull request Mar 12, 2019
This is a hold-over until babel#9641 is released.
matt-tingen added a commit to matt-tingen/babel that referenced this pull request Mar 12, 2019
This is a hold-over until babel#9641 is released.
mAAdhaTTah added a commit to mAAdhaTTah/babel that referenced this pull request Mar 15, 2019
* master: (58 commits)
  Remove dependency on home-or-tmp package (babel#9678)
  [proposal-object-rest-spread] fix templateLiteral in extractNormalizedKeys (babel#9628)
  Partial application plugin (babel#9474)
  Private Static Class Methods (Stage 3) (babel#9446)
  gulp-uglify@3.0.2
  rollup@1.6.0
  eslint@5.15.1
  jest@24.5.0
  regexpu-core@4.5.4
  Remove input and length from state (babel#9646)
  Switch from rollup-stream to rollup and update deps (babel#9640)
  System modules - Hoist classes like other variables (babel#9639)
  fix: Don't transpile ES2018 symbol properties (babel#9650)
  Add WarningsToErrorsPlugin to webpack to avoid missing build problems on CI (babel#9647)
  Update regexpu-core dependency (babel#9642)
  Add placeholders support to @babel/types and @babel/generator (babel#9542)
  Generate plugins file
  Make babel-standalone an ESModule and enable flow (babel#9025)
  Reorganize token types and use a map for them (babel#9645)
  [TS] Allow context type annotation on getters/setters (babel#9641)
  ...
@christianalfoni
Copy link

christianalfoni commented Aug 2, 2019

Hm, is this part of the latest 7.3.3 release? Still getting:

getter must not have any formal parameters

errors on this? Might be our setup, but yeah, just wanted to ask :)

Or maybe it was just solved for classes? I am using it on plain objects:

{
  foo(this: Foo) {

 }
}

@matt-tingen
Copy link
Contributor Author

@christianalfoni This was released in 7.4.0. It's still working for me in the REPL.

@christianalfoni
Copy link

Oh, hm, it seems that @babel/preset-typescript is not keeping up with latest versions?

@matt-tingen
Copy link
Contributor Author

@christianalfoni I'm not sure how the auxiliary packages are versioned. Most of them seem to keep in sync with core, but some may not need any changes for a given core bump.
In my project, we are using @babel/core 7.4.0 and @babel/preset-typescript 7.3.3. If you need help getting it set up, I would suggest posting on StackOverflow.

@nicolo-ribaudo
Copy link
Member

We only publish updated packages when they are actually changed. @babel/preset-typescript hasn't changed, but only one of its dependencies: @babel/plugin-transform-typescript.

One of these commands should work:

npm update @babel/plugin-transform-typescript

yarn upgrade @babel/plugin-transform-typescript

@lock lock bot added the outdated A closed issue/PR that is archived due to age. Recommended to make a new issue label Nov 2, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Nov 2, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area: typescript outdated A closed issue/PR that is archived due to age. Recommended to make a new issue pkg: parser PR: Spec Compliance 👓 A type of pull request used for our changelog categories
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Typescript: getters with this
6 participants