namespaces don't respect `const`s

[pushkine]

🔎 Search Terms

namespace const generated

🕗 Version & Regression Information

ts stable & nightly

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.8.3#code/KYDwDg9gTgLgBAOwIYFtgGcxIMbDgMQgjgG8AoOSuUSWObCBdeAMyLgF5SBfAbgqo1orAK4JsMAJaM4AIyRQAFAEpScKMBgioCOGwi843MtyA

💻 Code

export namespace Foo {
    export const foo = {};
    export function bar() { return foo; }
}

🙁 Actual behavior

export var Foo;
(function (Foo) {
    Foo.foo = {};
    function bar() { return Foo.foo; }
    Foo.bar = bar;
})(Foo || (Foo = {}));

const <name> is not generated, and typecript injects property accessors <namespace>.<name>

🙂 Expected behavior

export var Foo;
(function (Foo) {
    const foo = {};
    Foo.foo = foo;
    function bar() { return foo; }
    Foo.bar = bar;
})(Foo || (Foo = {}));

const <name> is generated, and typescript does not inject property accessors

Additional information about the issue

I'd expect export let/var <name> variables to work this way since they can be modified, but consts should be declared as consts in the codegen.

[jcalz]

Is there something observably wrong about the behavior of the emitted code? Or you just don't like that the emitted code doesn't use const inside it?

I'd think for this to be a possible bug, you'd need to see code that compiles without error, but produces observably different behavior at runtime. And indeed one can do that, but const doesn't seem to be the issue here, since it's much easier to expose with let/var:

namespace Foo {
    export let foo = 0; 
    export function bar() { return foo; }
}

Foo.foo = 1; // this is not a compiler error, *unless* foo is const above
console.log(Foo.bar()) // displays 0 or 1 depending on the emitted code, uh oh

This feels like a bug to me (or at least behavior that needs explaining), but I can't tell if it's the bug you're trying to report, or if it's just a different bug I found while trying to understand what you're reporting.

[MartinJohns]

Is there something observably wrong about the behavior of the emitted code?

Foo.foo could be reassigned, making Foo.bar() return the newly assigned value instead of the original one. That's likely what OP refers to.

[jcalz]

Sure, that's what I'm showing in my example, but const mitigates this by giving a compiler error on that reassignment. It's arguably worse to do this with let or var, where there's no compiler error but you're still getting wrong (or confusing) behavior. Does const have anything to do with the issue? Are you and I identifying a different issue that the OP isn't trying to report?

[pushkine]

To be clear my problem is with codegen inside the local namespace scope, not reassignment typechecking. I'm declaring a const in the scope so I'm expecting to have a const in the scope, not property accessors. I'm expecting the behavior to be the same as the function declaration, which is codegen'd into a real function declaration and doesn't replace every A by Foo.A in the local scope.

namespace Foo {
    export function A() {}
    A; // actual: A;    <--- good!

    export const B = 1;
    B; // actual: Foo.B;   <--- bad! expected just B
}

namespace Foo {
    A; // actual: Foo.A;    <--- good!
    B; // actual: Foo.B;    <--- good!
}

My actual real-world issue is that in my namespace scope where I declare B, I also have a function that iterates over 30k ThreeJS objects on every frame. Codegen turning B into Foo.B has non-negligible performance implications

[jcalz]

So you might want to edit your top post to mention that it's a performance issue, and possibly rephrase it as a feature request. It isn't a bug that JS transpiles/downlevels code for the target runtime, and it's arguably not a bug that it does so in a way that isn't completely optimized for your particular use case. Anyway, it seems the issue @MartinJohns and I see with the emit has absolutely nothing to do with your issue, so I'll stop talking about it here and maybe open a new issue for it, so as to cut down on noise. Good luck!

[RyanCavanaugh]

AFAIK this is the very first perf complaint we've gotten in the dozen years of the codegen being this way. If you have a perf-critical local read, making a local alias seems entirely reasonable for the sake of not breaking who knows what code that has some kind of hidden dependency on this exact emit (one could imagine some people being overly clever and doing unchecked writes to Foo.foo because they assumed this would always work).

[typescript-bot]

This issue has been marked as "Not a Defect" and has seen no recent activity. It has been automatically closed for house-keeping purposes.