strip: Class fields should be assigned after parameter properties

[nayeemrmn]

Input code

TypeScript allows regular class fields to depend on parameter properties:

class A {
  b = this.a;
  constructor(public a: any) {}
}

Output code (actual)
The regular class field b is incorrectly initialised before the parameter property a:

class A {
    b = this.a;
    constructor(a){
        this.a = a;
    }
}

Output code (expected)
The correct ordering is, parameter property assignment -> class field initialisation -> rest of the constructor. So if there are parameter properties present (or always), the class field initialisation must be moved below their assignments in the constructor:

class A {
    constructor(a) {
        this.a = a;
        this.b = this.a;
    }
}

This is the official compiler's output.

---

Seen in https://github.com/denoland/deno/blob/v1.2.2/std/mime/multipart.ts#L263-L271

cc @bartlomieju

[kdy1]

This is handled by class properties pass. Note that class properties pass inject some helpers and you need InjectHelper pass. (I don't know why. I just looked at the output from the babel and write code to emit same output.)

If it's not acceptable, I can modify typescript pass to do it or class properties pass not to inject helper

[Brooooooklyn]

Seems like TypeScript default behavior is different between the ECMA class field proposal: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#the-usedefineforclassfields-flag-and-the-declare-property-modifier.

So I think:

I can modify typescript pass to do it

is a better way to handler this situation. And because class properties need to be handled with parameter properties

[kdy1]

I think modifying class_properties pass to accept mode is better than modifying typescript_strip pass because typescript also supports useDefineForClassFields . If I modify typescript_strip pass, I have to do same work twice

[kdy1]

Now there exists a typescript_class_properties pass for it.

[nayeemrmn]

@kdy1 I'm still seeing this issue in deno cache --no-check with Deno on master. Has something not been updated or configured properly? https://github.com/denoland/deno/blob/v1.3.1/Cargo.lock

[bartlomieju]

@nayeemrmn I forgot to add typescript_class_properties to our setup 🤦

[swc-bot]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.