Babel emits properties for type-only properties in typescript classes

[aaronjensen]

Bug Report

Current Behavior
When a class is defined like:

class Foo {
  bar!: string
}

And the typescript preset + class-properties is applied the generated code ends up including that property set to void 0 which differs from TypeScript.

class Foo {
  constructor() {
    this.bar = void 0;
  }

}

Input Code

https://github.com/aaronjensen/typescript-babel-repro

Expected behavior/code

It should not emit the property unless it has an assignment.

class Foo {
}

Babel Configuration (.babelrc, package.json, cli command)

Note: loose is not important--the bug exists either way. It just simplifies the output.

{
  "presets": ["@babel/preset-typescript"],
  "plugins": [
    [
      "@babel/plugin-proposal-class-properties", { "loose": true }
    ]
  ]
}

Environment

• Babel version(s): v7.0.0-beta.47
• Node/npm version: Node 8/yarn 1.6.0
• OS: macOS 10.13.4
• Monorepo: no
• How you are using Babel: repro cli, project loader

[babel-bot]

Hey @aaronjensen! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

[hzoo]

This is intentional, as we aren't trying to match typescript behavior/output, just allow you to use Babel with Typescript, so this is just spec behavior that is included in loose mode.

Meaning the opposite thing was requested in #5056. So not a bug, just whether we would be ok with updating loose mode to not include the undefined which is ok to me (unrelated to typescript).

[aaronjensen]

I see. Well, if it's to spec then I don't see any reason to make loose mode go more against spec. I already have a workaround for this (define the types in a .d.ts) and perhaps saying bar: string = this.bar would work as well, at the cost of more confusion and hackiness.

Anyway, I'll close this, thank you for responding!

[hzoo]

I think it's a valid request for loose mode though, can reopen as a separate request as well! Probably someone like @developit would appreciate. This goes into my desire to make more granular options + loose mode just turning on all the more granular ones.

[aaronjensen]

I think my concern would be that the behavior would change if one toggled from non-loose to loose. Perhaps it wouldn't change in a way that anyone would care about, but I cared about it 😄

[hzoo]

that the behavior would change if one toggled from non-loose to loose

Well that is expected, loose means you are opting into a less spec compliant output/semantics and you should know what you are getting into if you want less build size - a tradeoff. It's not a concern in the definition, just that most people don't understand what it means and we need better education/docs on all this (which I will try to do soon)