You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have researched what is preventing the expando static prop to be added to exports, and it is due to when a ts.Symbol is considered for expando properties, here:
Specifically, the symbol's flag of A inside the UMD wrapper are not sufficient to take the early-return in the first statement, whereas with A at the top-level it has been assigned appropriate flags.
Because the appropriate flags are not present, the code structure is analyzed to determine if the symbol should be classified as expando. Specifically, the relevant code is in getExpandoInitializer:
From this function, it becomes clear why the symbol fails to be recognized as expando symbol: the used IIFE syntax deviates from the syntax that is accounted for in getExpandoInitializer. When changing the sample into the following, it does indeed work as expected:
(function(){varA=(function(){functionA(){}returnA;})();// <-- The difference is hereA.expando=true;}());
Unfortunately however, downleveled ES5 code does use the syntax that is not accounted for.
Playground Link:
Can't be replicated in the playground, but copying the code into https://ts-ast-viewer.com, setting the script kind to JS and inspecting the Symbol of the outer A declaration shows that its exports are empty. The alternative IIFE syntax does have the proper exports.
Related Issues:
n/a
Background info
This is an issue for Angular's Compatibility Compiler, which uses the TypeScript compiler to parse JavaScript bundles in various formats and uses the symbol information to reason about the code. PR angular/angular#30795 now contains a hack to patch TS's getExpandoInitializer, which does indeed resolve the issue.
The text was updated successfully, but these errors were encountered:
I tried to create a testcase tests/cases/conformance/salsa/typeFromPropertyAssignment38.ts to replicate the issue, however the following didn't work out:
TypeScript Version: 3.4.0, 3.5.0, master (7dc1f40)
Search Terms:
expando, iife, umd, exports
Code
Given the following code, similar to an UMD file:
Expected behavior:
The
ts.Symbol
of the outerA
should haveexpando
in it.Actual behavior:
The
ts.Symbol
of the outerA
does not haveexpando
in it. When the declaration ofA
is at the top-level, without the "UMD wrapper", it works properly:I have researched what is preventing the
expando
static prop to be added to exports, and it is due to when ats.Symbol
is considered for expando properties, here:TypeScript/src/compiler/binder.ts
Lines 2649 to 2678 in 3d2af9f
Specifically, the symbol's flag of
A
inside the UMD wrapper are not sufficient to take the early-return in the first statement, whereas withA
at the top-level it has been assigned appropriate flags.Because the appropriate flags are not present, the code structure is analyzed to determine if the symbol should be classified as expando. Specifically, the relevant code is in
getExpandoInitializer
:TypeScript/src/compiler/utilities.ts
Lines 1873 to 1896 in 3d2af9f
From this function, it becomes clear why the symbol fails to be recognized as expando symbol: the used IIFE syntax deviates from the syntax that is accounted for in
getExpandoInitializer
. When changing the sample into the following, it does indeed work as expected:Unfortunately however, downleveled ES5 code does use the syntax that is not accounted for.
Playground Link:
Can't be replicated in the playground, but copying the code into https://ts-ast-viewer.com, setting the script kind to JS and inspecting the Symbol of the outer
A
declaration shows that itsexports
are empty. The alternative IIFE syntax does have the properexports
.Related Issues:
n/a
Background info
This is an issue for Angular's Compatibility Compiler, which uses the TypeScript compiler to parse JavaScript bundles in various formats and uses the symbol information to reason about the code. PR angular/angular#30795 now contains a hack to patch TS's
getExpandoInitializer
, which does indeed resolve the issue.The text was updated successfully, but these errors were encountered: