Open sjamesr opened 1 year ago
It'd be an issue in both; this library is just the same helpers that TS emits but pulled out for common reuse.
@rbuckton
Looking closer at the error in question, it seems like it's trying to set the name
property of HTMLScriptElement
. Can you provide an example of the emit where this error is produced? If this is somehow a reference to the existing DOM HTMLScriptElement
constructor, there's no reason we should be setting a name
for it, so it would be helpful to see how things got into that state.
In a TS file, we have:
function foo() {
const clazz = class {static bar = true;}
}
The output I get from tsc is:
function foo() {
var _a;
const clazz = (_a = class {
},
__setFunctionName(_a, "clazz"),
_a.bar = true,
_a);
}
I think this snippet should fail on Cobalt 9 (it emits the problematic __setFunctionName call), but I haven't tried it.
Per my comment earlier, I'm not sure the issue is __setFunctionName
specifically, but how it is somehow being applied to an HTMLScriptElement
per the TypeError in the issue description. Somehow __setFunctionName
is being applied to the wrong thing in your project.
We can no longer reproduce this failure. Please feel free to close the issue.
We've observed new behavior after upgrading our code to TypeScript 5.0. Specifically, TS5.0 emits calls to a new tslib helper function
__setFunctionName
. This in turn callsObject.defineProperty(x, "name", ...)
on the class, which seems to fail on Cobalt 9:We're not sure whether this is an issue with tslib, TS5.0 or with the calling code (in our case I think it's a Jasmine test). I'd be grateful for any guidance the tslib team could provide.