-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
@action field uses addInitializer from decorator context but that does not exist in the (new) spec #3817
Comments
Additional info. Looks like the spec readme text is outdated against the spec text and this might be an swc bug (see referenced issues) |
@phiresky The spec has been revised - I'm not super familiar with SWC, but high-level it re-implements Typescript's transpiler, yeah? Otherwise, I would think that maybe update TS, but I don't think that's applicable. I have no authority of the repo here, so I'll let someone else weigh-in more officially, but my thought would be to look for/post an issue with SWC (if all versions there are current) and use |
Intended outcome:
@action decorators should work with fields (lambdas).
Actual outcome:
It throws
addInitializer
is not a function. The reason is this code:mobx/packages/mobx/src/types/actionannotation.ts
Lines 70 to 78 in df7e1eb
How to reproduce the issue:
@action foo = () => {};
The context passed by the decorator looks like this:
{"kind":"field","name":"addFiles","static":false,"private":false,"metadata":{},"access":{}}
Versions
Spec reference
If you look at the class field spec, it says this: https://github.com/tc39/proposal-decorators#class-fields
The interface of the decorator looks like this:
So probably instead of using addInitializer the initializer should be returned.
cc @Matchlighter
I think this issue is not visible when using babel because babel does support addInitializer (in conflict with the spec). But it does appear when compiling with
swc
(which follows the spec)The text was updated successfully, but these errors were encountered: