Include non-enumerable keys in __importStar helper

[Ron Buckton (rbuckton)]

This changes the __importStar helper to include non-enumerable own keys to ensure the following two cases are consistent:

// tsimportA,{b}from"mod";A;b;// jsconstmod_1=__importStar(require("mod"));mod_1.default;mod_1.b;

vs

// tsimportAfrom"mod";import{b}from"mod";A;b;// jsconstmod_1=__importDefault(require("mod"));constmod_2=require("mod");mod_1.default;mod_2.b;

The discrepancy occurs when the module "mod" produces exports that are non-enumerable, such as:

classC{staticb(){}}module.exports=C;

In the above case, C.b is an own static method of C which makes it non-enumerable by default.

The other way to address this would be to also wrap mod_2's require in __importStar so that we apply the rule consistently in both cases, but that would be a major breaking change as it has the potential to break existing users w/o warning.

The companion PR for tslib can be found at microsoft/tslib#272.

Fixes#45133

[Jake Bailey (jakebailey)]

Was there a typo? #41533 seems unrelated.

Should this have waited for 5.8 since it's an emit change?

[Ron Buckton (rbuckton)]

It's a bugfix to an emit helper and I would say the risk of it being an issue is fairly small given that it is more permissive. Going the other direction I mentioned in the OP would have needed to wait for 5.8 as it would be a breaking change.

[Ron Buckton (rbuckton)]

Was there a typo? #41533 seems unrelated.

Yeah, that should have been #45133.