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

Add compiler options to disable decorator transform #16882

Closed
cncolder opened this issue Jul 1, 2017 · 8 comments
Closed

Add compiler options to disable decorator transform #16882

cncolder opened this issue Jul 1, 2017 · 8 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@cncolder
Copy link

cncolder commented Jul 1, 2017

We missing an option to disable decorator transform. Code below preserveDecorators option is virtual.

TypeScript Version: 2.4.0

Code

tsconfig.json

{
  "compilerOptions": {
    "target": "es2017",
    "module": "es2015",
    "experimentalDecorators": true,
    "preserveDecorators": true
  }
}

index.ts

class Foo {
  @autobind
  onClick(e: Event) {
    console.log(e)
  }
}

Expected behavior:

index.js

class Foo {
  @autobind
  onClick(e) {
    console.log(e);
  }
}

Actual behavior:

index.js

class Foo {
  onClick(e) {
    console.log(e);
  }
}
__decorate([
    autobind
], Foo.prototype, "onClick", null);
@mhegazy
Copy link
Contributor

mhegazy commented Aug 23, 2017

It will be possible once we implement the new decorators proposal using --target ESNext.

@mhegazy mhegazy added the Working as Intended The behavior described is the intended behavior; this is not a bug label Aug 23, 2017
@mhegazy
Copy link
Contributor

mhegazy commented Sep 6, 2017

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

@mhegazy mhegazy closed this as completed Sep 6, 2017
@aluanhaddad
Copy link
Contributor

aluanhaddad commented Sep 6, 2017

@mhegazy I noticed this was automatically closed just now but I think it is worth considering a dedicated flag for this assuming that metadata emit is something that will be supported in some form by the new implementation. This would mean that TypeScript and Babel will continue to have very different behaviors.

Currently, using --target esnext transforms decorators while retaining other prospective syntax. If this were to change it would break a large number of existing workflows. Of course, all existing code will need to be updated to employ decorators from the new proposal, but the current multi-transpiler setups used on certain projects still seem reasonable.

On the other hand, if metadata emit is actually dropped then it does make sense to control this with --target.

@mhegazy
Copy link
Contributor

mhegazy commented Sep 6, 2017

Once we implement the new proposal it becomes an esNext feature, it will be passed thorough in esNext and transfomred otherwise. currently the semantics are different, so the compiler would tell something that does not match what babel would transform.

@mhegazy
Copy link
Contributor

mhegazy commented Sep 6, 2017

metadata is a different issue. it will be transformed as a decorator in --target esNext. e.g. @ __metadata("design:paramtypes", [Number, String])

@aluanhaddad
Copy link
Contributor

@mhegazy

metadata is a different issue. it will be transformed as a decorator in --target esNext. e.g. @ __metadata("design:paramtypes", [Number, String])

That seems very elegant and addresses all of my concerns. Thank you for explaining.

@timwangdev
Copy link

Please reopen this issue, since #18713 is labeled duplicate with this.

@kitsonk
Copy link
Contributor

kitsonk commented Sep 29, 2017

As explained in this issue and the other issue, this is intended behaviour. Therefore this issue is closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

5 participants