[Bug]: Order of constructor parameter properties vs class properties initializers - Discrepency between typescript and bable
See original GitHub issueš»
- Would you like to work on a fix?
How are you using Babel?
Input code
Original Code:
class Dashboard {
name = 'stats' + this.amount;
constructor(
readonly amount
) {
}
}
Babel Emit:
"use strict";
function _defineProperty(obj, key, value) { if (key in obj) { Object.defineProperty(obj, key, { value: value, enumerable: true, configurable: true, writable: true }); } else { obj[key] = value; } return obj; }
class Dashboard {
constructor(amount) {
_defineProperty(this, "name", 'stats' + this.amount);
this.amount = amount;
}
}
Typescript emits:
class Dashboard {
constructor(amount) {
this.amount = amount;
this.name = 'stats' + this.amount;
}
}
Configuration file name
babel.config.js
Configuration
For reproduction Iāve used the Babel online repl with Env stage 2 preset and Typescript preset. link
For typescript reproduction Iāve used Typescript playground. link
Current and expected behavior
Current Behavior - Babel puts parameter properties in the constructor after class properties assignment. Typescript puts them before.
Expected Behavior - Its a discrepancy. Not sure if Babel is the responsible or Typescript. Typescript behavior is more preferable to me because it makes writing shorter for me.
Environment
- Babel - 7.15.7
- Typescript - 4.4.2
Possible solution
Not sure. Iāve found some issues talking about plugin orders but Iām not sure.
Additional context
No response
Issue Analytics
- State:
- Created 2 years ago
- Reactions:4
- Comments:5 (4 by maintainers)
Top Results From Across the Web
Why are derived class property values not seen in the base ...
First up, this is not a bug in TypeScript, Babel, or your JS runtime. ... to transform the field initialization to a constructor...
Read more >babel/plugin-transform-typescript
This plugin adds support for the types syntax used by the TypeScript programming language. However, this plugin does not add the ability to...
Read more >Documentation - TypeScript 3.7
The āshort-circuitingā behavior that optional chains have is limited property accesses, calls, element accesses - it doesn't expand any further out from ......
Read more >Property Initializers: What, Why, and How to Use It - ITNEXT
The new class āproperty initializersā allows you to define methods (or any property) in your React components using regular ES6 classes ...
Read more >Strict mode - JavaScript - MDN Web Docs
In sloppy mode, mistyping a variable in an assignment creates a new property on the global object and continues to "work".
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
When comparing TS with Babel, you should always enable the
useDefineForClassFields
TS option: itās the option that makes TS class fields like JS class fields, which is what Babel does and what TC will do in a future version.After enabling that option, if you target ES2015-ES2021 it will first initialize
this.amount
and thenthis.name
. However, if you target ESNext (and soon ES2022, when itās supported), it first initializesthis.name
and thenthis.amount
.I suggest reporting this inconsistency to the TS team: when theyāll decide which is the correct order weāll do the same.
Yeah, but MDN doesnāt define parameter properties, which are a TS extension.