ES2022 Class Decorators not working when Class has self-static member #52004

vladimir-siv · 2022-12-23T18:32:58Z

Bug Report

Class decorators are not working properly when the class has a static field of the same type and is instantiating it statically. Seems like this only happens when targeting ES2022.

🔎 Search Terms

Various combinations of the below search strings. Haven't been able to find anything useful.
Been searching for several days now, these are just the most recent ones I could remember:

Typescript class decorator with static property not working
Typescript decorators: TypeError: undefined is not a constructor
Typescript decorators not working (with es2022)
Typescript decorator es2022
Angular custom decorators not working
Angular custom decorators with aot

🕗 Version & Regression Information

Regressed when tsconfig.compilerOptions.target is ES2022. Other ES versions that I tried seem to be working as expected.
Tried Nightly version in the playground, could still repro it (after I changed target to ES2022 in TSConfig).

⏯ Playground Link

Bug repro in Playground
You can try setting e.g. ES2021, and the code works, but not on ES2022.

💻 Code

src\index.ts:

function Message(ctor: Function)
{
    console.log(`Registring: "${ctor.name}"`);
}

@Message
class PingMessage
{
    public static Default: PingMessage = new PingMessage(); // [A]
    public constructor(public readonly Value: string = "Ping") { }
}

// PingMessage.Default = new PingMessage(); // [B]
console.log(PingMessage.Default.Value);

// Swapping instantiation from [A] to [B] renders this code working.
// Seems like constructor is not defined well while instantiating a static member within its own class.

package.json:

{
  "name": "decorator-test",
  "version": "1.0.0",
  "description": "Test App",
  "scripts": {
    "start": "(if exist dist rd /S /Q dist) >nul 2>nul && tsc && node ./dist/index.js"
  },
  "dependencies": {
    "tslib": "^2.4.1"
  },
  "devDependencies": {
    "typescript": "^4.9.4"
  }
}

tsconfig.json:

{
  "compileOnSave": false,
  "compilerOptions": {
    "baseUrl": "./",
    "outDir": "./dist",
    "target": "ES2022",  // <----- !!!
    "module": "ES2022",
    "strict": true,
    "experimentalDecorators": true,
    "useDefineForClassFields": false,
    "lib": [
      "ES2022",
      "dom"
    ]
  },
  "files": [
    "src/index.ts"
  ]
}

🙁 Actual behavior

~\dist\index.js:13
static { this.Default = new PingMessage_1(); } // [A]
^

TypeError: undefined is not a constructor
at Function.<static_initializer> (~\dist\index.js:13:29)
at Object. (~\dist\index.js:12:19)
at Module._compile (node:internal/modules/cjs/loader:1155:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1209:10)
at Module.load (node:internal/modules/cjs/loader:1033:32)
at Function.Module._load (node:internal/modules/cjs/loader:868:12)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
at node:internal/main/run_main_module:22:47

🙂 Expected behavior

Console.logs:

Registring: "PingMessage"
Ping

The text was updated successfully, but these errors were encountered:

rbuckton · 2023-01-05T20:05:39Z

The binding for PingMessage_1 is initialized too late. I believe I've fixed this for Stage 3 decorators, but not for legacy decorators.

rbuckton · 2023-01-05T20:13:54Z

When targeting ES2022+, the emit for the example above is currently:

let PingMessage = PingMessage_1 = class PingMessage {
    static { this.Default = new PingMessage_1(); }
    constructor(Value = "Ping") {
        this.Value = Value;
    }
};
PingMessage = PingMessage_1 = __decorate([
    Message,
    __metadata("design:paramtypes", [String])
], PingMessage);

However, PingMessage_1 isn't yet initialized. The emit should probably be this instead:

let PingMessage = PingMessage_1 = class PingMessage {
    static { PingMessage_1 = this; }
    static { this.Default = new PingMessage_1(); }
    constructor(Value = "Ping") {
        this.Value = Value;
    }
};
PingMessage = PingMessage_1 = __decorate([
    Message,
    __metadata("design:paramtypes", [String])
], PingMessage);

Please note that class decorators and static initializers that reference this or the class constructor don't play well together under --experimentalDecorators because static initializers run before decorators are applied. That ordering can be problematic when a class decorator performs constructor replacement as the initializer will not use the replacement constructor. In the Stage 3 Decorators proposal, decorators are applied before static initializers instead.

As a workaround, you could lazily initialize the value so that the constructor is run later:

@Message
class PingMessage
{
        private static _Default: PingMessage | undefined;
	public static get Default() { return PingMessage._Default ??= new PingMessage(); }
	public constructor(public readonly Value: string = "Ping") { }
}

vladimir-siv · 2023-01-05T20:41:04Z

No worries, feel free to close the issue, there are several ways to work around this, I made a similar workaround, just wanted to report this issue.

markwhitfeld · 2023-01-07T22:26:00Z

Came across this issue recently. I believe it is in fact a TS bug that needs to be resolved.
The issue is caused by the aliased class name, which is not initialised at the time of the static initialisers being called, where the class itself is, in fact, available from within the static initialisers in ES2022.

Given the following TS Code:

function createFromClass(caller: string, classRef: unknown) {
    console.log(`${caller}:`, classRef);
    return 'foo';
}

function SomeDecorator(): ClassDecorator {
    return () => { };
}

class UndecoratedClass {
    static test = createFromClass('UndecoratedClass', UndecoratedClass);
}

@SomeDecorator()
class DecoratedClass {
    static test = createFromClass('DecoratedClass', DecoratedClass);
}

If this is run targeting ES2021 or earlier then the class is available to the static initialisers for both UndecoratedClass and DecoratedClass. But, if we target ES2022 or later then the DecoratedClass class receives undefined as its reference to itself from within its static initialisers.
This is a result of the intermediary ..._1 class reference in the generated code not being populated yet:

let DecoratedClass = DecoratedClass_1 = class DecoratedClass {
    static test = createFromClass('DecoratedClass', DecoratedClass_1);
};
DecoratedClass = DecoratedClass_1 = __decorate([ SomeDecorator() ], DecoratedClass);

When there is no decorator, then the intermediary reference is not created and it all works as expected.

Here is a playground of the above example:
https://www.typescriptlang.org/play?target=9#code/GYVwdgxgLglg9mABBATgUwIZTQMRXAWwGEAbDAZ3IAoIMSS0UAuRcqFGMAcwBpkzKAJTTAW4ANZg4AdzABKRAG8AUIjXIE5OAwB0JOFyoADACSLa9RgF8mRvhAHlhwOQG5V69FBAokAcmA4OD93K2VlUEhYBEQAZUI0ABE0CDgULDSqORZSCnJk1PSoNKUPNS8fJCzEAF4APiVEK1DwhzzEAFUwABMUtKw0btzKUvVWKCwYCERsNlrkdAG8QmHqPy7ewoGhxz8+Db6iwdW3ZTDlAAF4giTDjJQs5TaRgv7sHfaVMbZJ6dmoeaoTDYZbERxUPyvI4fSh7RBQ7YnUJAA

Proposed solution

Not sure all the reasons for the intermediary class reference, but potentially an alternative would be for TS to generate the following JS code when a decorator is used:

let DecoratedClass = (() => {
    class DecoratedClass {
        static {             
            this.test = createFromClass('DecoratedClass', DecoratedClass); 
        }
    };
    return __decorate([ SomeDecorator() ], DecoratedClass);
})()

The code above effectively uses a shadowed variable name within the IIFE as the intermediary class reference to the same effect, but without the reference initialisation timing issue.
This even allows for less of a need for modification of the decorated class code and the final code has fewer characters (ignoring whitespace).
@rbuckton What do you think of this proposed approach for legacy decorators?

(EDIT: It could even be trimmed down to the following, but it really depends on the reason for the intermediary reference as to how far we simplify this.)

let DecoratedClass = (() => 
  __decorate([ SomeDecorator() ],
    class DecoratedClass {
      static {
        this.test = createFromClass('DecoratedClass', DecoratedClass);
      }
    }
  )
)();

markwhitfeld · 2023-03-02T06:51:08Z

I am seeing more and more Angular projects running into this issue.
@rbuckton is there any plan to address this issue soon?
Hopefully my proposed solution above could provide some ideas.

rbuckton · 2023-03-02T16:21:17Z

Not sure all the reasons for the intermediary class reference, [...]

ECMAScript classes are "doubly bound", which means that the class name (i.e., DecoratedClass) is bound both outside the class and inside the class body, separately. This differs both from function declarations, which only bind the function name outside of the function, and function expressions, which only bind the function name inside of the function. The result of this behavior is that any reference to DecoratedClass inside of the class body will always be the original class, even if a class decorator replaces the constructor:

class A {
  static foo() { console.log(A.name); }
}

// replace A with B
A = class B extends A { }

// print the current name of A
console.log(A.name); // B

// indirectly print the name of A that the 'foo' method sees:
A.foo(); // A

[...] but potentially an alternative would be for TS to generate the following JS code when a decorator is used:
let DecoratedClass = (() => {
    class DecoratedClass {
        static {             
            this.test = createFromClass('DecoratedClass', DecoratedClass); 
        }
    };
    return __decorate([ SomeDecorator() ], DecoratedClass);
})()
The code above effectively uses a shadowed variable name within the IIFE as the intermediary class reference to the same effect, but without the reference initialisation timing issue. This even allows for less of a need for modification of the decorated class code and the final code has fewer characters (ignoring whitespace). @rbuckton What do you think of this proposed approach for legacy decorators?

I'm not sure what you mean by "shadowed variable" in this context, but unfortunately this doesn't work per the reason I stated above.

(EDIT: It could even be trimmed down to the following, but it really depends on the reason for the intermediary reference as to how far we simplify this.)
let DecoratedClass = (() => 
  __decorate([ SomeDecorator() ],
    class DecoratedClass {
      static {
        this.test = createFromClass('DecoratedClass', DecoratedClass);
      }
    }
  )
)();

This also wouldn't work since DecoratedClass wouldn't be the replaced constructor.

The only change I could see us making would be to more closely emulate native decorators with regards to the timing of static initializer evaluation, such that where we previously ran static initializers before decorators, we would run them after decorators. However, I'm not certain whether there are customers that might be affected by such a major semantics change. I'm more likely to err on the side of caution and make it an error to reference the class name immediately within a static initializer (much like we do for a TDZ check for let/const).

I would still suggest using lazy initialization for these fields, as I mentioned above.

markwhitfeld · 2023-03-08T21:31:44Z

@rbuckton I have spent some time trying to understand the problem, and I found your commit here which resolved this issue as well as the double binding problem.

EDIT. I have found a better solution in my comment below: #52004 (comment)
Leaving the body of this comment here as a collapsible section if anyone is interested in the thought progression.

Expand to see comment body

I think I have found a solution that would cover these cases and would additionally allow code to function in the same way when targeting ES2022 as when we target ES2021 or earlier.

Given the following TS code:

@SomeDecorator()
class DecoratedClass {
    static test1 = doSomething('DecoratedClass', DecoratedClass);
    static test2 = DecoratedClass;
    static test3() { return DecoratedClass; }
}

and assuming that the SomeDecorator decorator did something dramatic to modify the constructor, like this:

function SomeDecorator() {
    return (target) => {
        return class ModifiedClass extends target {};
    };
}

Today, if we compile with ES2021, we get:

let DecoratedClass = DecoratedClass_1 = class DecoratedClass {
    static test3() { return DecoratedClass_1; }
};
DecoratedClass.test1 = doSomething('DecoratedClass', DecoratedClass_1);
DecoratedClass.test2 = DecoratedClass_1;
DecoratedClass = DecoratedClass_1 = __decorate([
    SomeDecorator()
], DecoratedClass);

This results in the following observations:

DecoratedClass.test1 has its initialiser called with DecoratedClass before the decorator ran
DecoratedClass.test2 references the DecoratedClass from before the decorator
DecoratedClass.test3, when invoked would return ModifiedClass (as returned by the decorator)

Today, if we compile with ES2022, we get:

let DecoratedClass = DecoratedClass_1 = class DecoratedClass {
    static { this.test1 = doSomething('DecoratedClass', DecoratedClass_1); }
    static { this.test2 = DecoratedClass_1; }
    static test3() { return DecoratedClass_1; }
};
DecoratedClass = DecoratedClass_1 = __decorate([
    SomeDecorator()
], DecoratedClass);

This results in the following observations:

DecoratedClass.test1 has its initialiser called with undefined
DecoratedClass.test2 is undefined
DecoratedClass.test3, when invoked would return ModifiedClass (as returned by the decorator)

1 and 2 are breaking changes!

This would be fixed if the code generated when targeting ES2022 was changed to:

let DecoratedClass = DecoratedClass_1 = class DecoratedClass {
    static { this.test = doSomething('DecoratedClass', this); }
    static { this.test1 = this; }
    static test2() { return DecoratedClass_1; }
};
DecoratedClass = DecoratedClass_1 = __decorate([
    SomeDecorator()
], DecoratedClass);

As you can see, references to DecoratedClass_1 have been replaced with this for the test1 and test2 initialisers.
So, if I understand things correctly, references to the containing class from static property initialiser expressions could be replaced with this, but static function declarations would still use the aliased name (DecoratedClass_1) in order to bind to the decorated class.

Do you think that this is a viable solution?

PS. I know that native decorators would do things differently here, but the "Experimental Decorators" have a different historical behavior in this regard, so I think that the historical behavior should be maintained for the experimental decorators.

markwhitfeld · 2023-03-08T21:46:19Z

EDIT. I have found a better solution in my comment below: #52004 (comment)
Leaving the body of this comment here as a collapsible section if anyone is interested in the thought progression.

Expand to see comment body

Just an additional note that a static initialiser like this:

static test4 = accessLater(function foo() { return DecoratedClass });

would also still need to return the aliased class DecoratedClass_1 and not this because the foo function has its own this that we would not want to be referencing.

But the potential issue here is that, depending on when this function is executed, the aliased class may not yet be available.
I'll play a bit more...

markwhitfeld · 2023-03-09T07:07:31Z

Ok, I think I have got a solution that will work for all scenarios.
I reworked the playground to make the expectations clearer too: See here

Trimmed TS example code:

console.log('=== Declaring: Original');

@SomeDecorator()
class Original {
    static test1 = init('Original', Original);
    static test2 = Original;
    static test3() { return Original; }
    static test4 = doNothing(function () { return Original });
    static test5 = Original?.test4();
}

console.log('--- After Declaration, should be Wrapped:', Original.name);
console.log(`'test1' should be Original:`, Original.test1?.name);
console.log(`'test2' should be Original:`, Original.test2?.name);
console.log(`'test3()' should return Wrapped:`, Original.test3()?.name);
console.log(`'test4()' should return Wrapped:`, Original.test4()?.name);
console.log(`'test5' should be Original:`, Original.test5?.name);

When run using ES2021, the output is:

[LOG]: "=== Declaring: Original" 
[LOG]: "In initialiser, should be 'Original':",  "Original" 
[LOG]: "INIT Decorator" 
[LOG]: "Decorating class:",  "Original" 
[LOG]: "--- After Declaration, should be Wrapped:",  "Wrapped" 
[LOG]: "'test1' should be Original:",  "Original" 
[LOG]: "'test2' should be Original:",  "Original" 
[LOG]: "'test3()' should return Wrapped:",  "Wrapped" 
[LOG]: "'test4()' should return Wrapped:",  "Wrapped" 
[LOG]: "'test5' should be Original:",  "Original"

All expectations align.

But, when run using ES2022, the output is:

[LOG]: "=== Declaring: Original" 
[LOG]: "In initialiser, should be 'Original':",  undefined 
[LOG]: "INIT Decorator" 
[LOG]: "Decorating class:",  "Original" 
[LOG]: "--- After Declaration, should be Wrapped:",  "Wrapped" 
[LOG]: "'test1' should be Original:",  undefined 
[LOG]: "'test2' should be Original:",  undefined 
[LOG]: "'test3()' should return Wrapped:",  "Wrapped" 
[LOG]: "'test4()' should return Wrapped:",  "Wrapped" 
[LOG]: "'test5' should be Original:",  undefined

Many cases are broken for ES2022.

Here is the current code emitted for the ES2022 target:

let Original = Original_1 = class Original {
    static { this.test1 = init('Original', Original_1); }
    static { this.test2 = Original_1; }
    static test3() { return Original_1; }
    static { this.test4 = doNothing(function () { return Original_1; }); }
    static { this.test5 = Original_1?.test4(); }
};
Original = Original_1 = __decorate([
    SomeDecorator()
], Original);

I think the best solution that covers all bases here is to add a static initialiser block at the top of the emitted class:

    static { Original_1 = this; }

Now the alias will be available to all the static initialiser blocks. Everything works!

Here is an example of the tweaked JS output code (playground) with just this one line added:

let Original = Original_1 = class Original {
    static { Original_1 = this; } // <-- PROPOSAL TO ADD THIS LINE
    static { this.test1 = init('Original', Original_1); }
    static { this.test2 = Original_1; }
    static test3() { return Original_1; }
    static { this.test4 = doNothing(function () { return Original_1; }); }
    static { this.test5 = Original_1?.test4(); }
};
Original = Original_1 = __decorate([
    SomeDecorator()
], Original);

@rbuckton what do you think of this solution?

PS. potentially the line: let Original = Original_1 = class Original {
could now be simplified: let Original = class Original {
because the alias is assigned internally. Although this is just a bundle size optimization.

rbuckton · 2023-04-27T21:01:47Z

let Original = Original_1 = class Original {
    static { Original_1 = this; } // <-- PROPOSAL TO ADD THIS LINE
    static { this.test1 = init('Original', Original_1); }
    static { this.test2 = Original_1; }
    static test3() { return Original_1; }
    static { this.test4 = doNothing(function () { return Original_1; }); }
    static { this.test5 = Original_1?.test4(); }
};
Original = Original_1 = __decorate([
    SomeDecorator()
], Original);

@rbuckton what do you think of this solution?

Yes, this will work fine. I should have a PR up for this shortly.

PS. potentially the line: let Original = Original_1 = class Original { could now be simplified: let Original = class Original { because the alias is assigned internally. Although this is just a bundle size optimization.

No, this will not work. Inside of a class body, the bound name of the class is immutable (constant) and cannot be changed.

rbuckton · 2023-04-27T21:03:48Z

PS. potentially the line: let Original = Original_1 = class Original { could now be simplified: let Original = class Original { because the alias is assigned internally. Although this is just a bundle size optimization.

No, this will not work. Inside of a class body, the bound name of the class is immutable (constant) and cannot be changed.

Sorry, I misread your suggestion. To clarify, you're stating that the Original_1 assignment in the let is unnecessary because it will be assigned in the first static block. Yes, this will work.

KurtGokhan · 2023-05-08T19:45:37Z

Will this be backported to 4.9? We are running into this issue in Angular 15 which uses TS 4.9 and targets ES2022 by default.

markwhitfeld · 2023-05-10T11:56:15Z

I agree that a backport would be really great. This bug is coming up many times in the Angular community.

lalo-mx · 2023-06-02T14:14:56Z

How likely is to be fixed in 5.0 branch? Angular 16 currently depends on 5.0 branch and looks like is expected to be fixed on TypeScript side angular/angular#49415

RyanCavanaugh · 2023-06-02T16:19:17Z

In general we only backport critical crashes or regression specific to a particular release, or issues without any workarounds. This doesn't appear to qualify for any of those criteria.

russcarver · 2023-09-15T05:01:47Z

This is still an issue with Angular 16.1.4 and Typescript 5.0.4 and a tsconfig with lib: es2022, module: es2022 and target of es2022. It's fine with a target of es2021.

According to the Angular upgrade matrix (https://gist.github.com/LayZeeDK/c822cc812f75bb07b7c55d07ba2719b3), for Angular 16.x.x, you must use Typescript >=4.9.5 <5.1.0

Has anyone tried Typescript >=5.1.0 with Angular ^16.1.4?

If no one knows the compatibility results, I'll give it a try and see what happens.

ericrovtar · 2023-12-04T20:39:09Z

This is still an issue with Angular 16.1.4 and Typescript 5.0.4 and a tsconfig with lib: es2022, module: es2022 and target of es2022. It's fine with a target of es2021.

According to the Angular upgrade matrix (https://gist.github.com/LayZeeDK/c822cc812f75bb07b7c55d07ba2719b3), for Angular 16.x.x, you must use Typescript >=4.9.5 <5.1.0

Has anyone tried Typescript >=5.1.0 with Angular ^16.1.4?

If no one knows the compatibility results, I'll give it a try and see what happens.

To answer this question: Yes, using TypeScript 5.1.3 with Angular 16.2.12 did the trick.

iqaan · 2025-03-26T08:04:39Z

Still an issue with Angular 17 (tried, 17.3.12) and TypeScript 5.4 (tried, 5.4.3)

RyanCavanaugh added the Needs Investigation This issue needs a team member to investigate its status. label Jan 4, 2023

RyanCavanaugh assigned rbuckton Jan 4, 2023

rbuckton added Bug A bug in TypeScript and removed Needs Investigation This issue needs a team member to investigate its status. labels Jan 5, 2023

MartinJohns mentioned this issue Jan 16, 2023

Static properties are not correctly transpiled when using decorators and target ES2022 #52258

Closed

JoostK mentioned this issue Jan 29, 2023

Initialisation of static members broken after upgrading from v15.0.4 to v15.1.0 angular/angular#48764

Closed

JeanMeche mentioned this issue Feb 22, 2023

"Uncaught TypeError: Cannot read properties of undefined" on static properties while executing ng test angular/angular#49160

Closed

markwhitfeld mentioned this issue Feb 22, 2023

❓[SUPPORT]: Compile for Ivy distribution ngxs/store#1818

Closed

markwhitfeld mentioned this issue Mar 8, 2023

🐞[BUG]: Latest Angular release has removed eivyEnabled ngxs/store#1974

Closed

fatcerberus mentioned this issue Mar 12, 2023

When the compile target is set to ES2022, an error will be reported at runtime #53218

Closed

JoostK mentioned this issue Mar 13, 2023

Angular component which references its own type and decorated by class decorator is broken when target es2022 angular/angular#49415

Closed

RyanCavanaugh added this to the TypeScript 5.1.0 milestone Mar 14, 2023

JoostK mentioned this issue Mar 21, 2023

public static readonly members not available in test angular/angular#49522

Closed

markwhitfeld mentioned this issue Apr 5, 2023

@Selector() State Parameter is undefined with v3.5.0 ngxs/store#1218

Closed

rbuckton mentioned this issue Apr 27, 2023

Fix class alias reference in static initializer for legacy class decorators #54046

Merged

typescript-bot added Fix Available A PR has been opened for this issue labels Apr 27, 2023

rbuckton closed this as completed in #54046 Apr 28, 2023

jzolnowski mentioned this issue May 29, 2023

Initialize cdk-tree component datasource in the constructor xlts-dev/angularjs-angular-hybrid-angular-cli#15

Merged

JoostK mentioned this issue Jun 13, 2023

Application doesn't boot with static fields and turned off aot angular/angular#50695

Closed

linear bot mentioned this issue Jul 19, 2023

chore: upgrade angular to 16 dasch-swiss/dsp-das#1153

Merged

v1nger125 mentioned this issue Sep 14, 2023

Angular 15 can't be build with es2022 and static members angular/angular#51770

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ES2022 Class Decorators not working when Class has self-static member #52004

ES2022 Class Decorators not working when Class has self-static member #52004

vladimir-siv commented Dec 23, 2022 •

edited

Loading

rbuckton commented Jan 5, 2023

rbuckton commented Jan 5, 2023 •

edited

Loading

vladimir-siv commented Jan 5, 2023

markwhitfeld commented Jan 7, 2023 •

edited

Loading

markwhitfeld commented Mar 2, 2023

rbuckton commented Mar 2, 2023

markwhitfeld commented Mar 8, 2023 •

edited

Loading

markwhitfeld commented Mar 8, 2023 •

edited

Loading

markwhitfeld commented Mar 9, 2023 •

edited

Loading

rbuckton commented Apr 27, 2023

rbuckton commented Apr 27, 2023

KurtGokhan commented May 8, 2023

markwhitfeld commented May 10, 2023

lalo-mx commented Jun 2, 2023

RyanCavanaugh commented Jun 2, 2023

russcarver commented Sep 15, 2023

ericrovtar commented Dec 4, 2023

iqaan commented Mar 26, 2025

ES2022 Class Decorators not working when Class has self-static member #52004

ES2022 Class Decorators not working when Class has self-static member #52004

Comments

vladimir-siv commented Dec 23, 2022 • edited Loading

Bug Report

🔎 Search Terms

🕗 Version & Regression Information

⏯ Playground Link

💻 Code

🙁 Actual behavior

🙂 Expected behavior

rbuckton commented Jan 5, 2023

rbuckton commented Jan 5, 2023 • edited Loading

vladimir-siv commented Jan 5, 2023

markwhitfeld commented Jan 7, 2023 • edited Loading

Proposed solution

markwhitfeld commented Mar 2, 2023

rbuckton commented Mar 2, 2023

markwhitfeld commented Mar 8, 2023 • edited Loading

markwhitfeld commented Mar 8, 2023 • edited Loading

markwhitfeld commented Mar 9, 2023 • edited Loading

rbuckton commented Apr 27, 2023

rbuckton commented Apr 27, 2023

KurtGokhan commented May 8, 2023

markwhitfeld commented May 10, 2023

lalo-mx commented Jun 2, 2023

RyanCavanaugh commented Jun 2, 2023

russcarver commented Sep 15, 2023

ericrovtar commented Dec 4, 2023

iqaan commented Mar 26, 2025

vladimir-siv commented Dec 23, 2022 •

edited

Loading

rbuckton commented Jan 5, 2023 •

edited

Loading

markwhitfeld commented Jan 7, 2023 •

edited

Loading

markwhitfeld commented Mar 8, 2023 •

edited

Loading

markwhitfeld commented Mar 8, 2023 •

edited

Loading

markwhitfeld commented Mar 9, 2023 •

edited

Loading