This pull request addresses a longstanding regression related to the unintended runtime leakage of imported symbols.
During the process of refactoring the internal symbol resolution code to achieve consistent handling of various symbols, an oversight occurred. This oversight caused the generated JavaScript runtime and the .d.ts files to inadvertently expose imported symbols of the stylesheet.
This situation is problematic because Stylable's assumption is that symbols of a stylesheet are only meant to be used if the stylesheet is imported into a JavaScript file. If it's not imported this way, it's assumed that the symbols' namespacing can't be connected to the DOM and can thus be removed as unnecessary code from the final output.
This fix is undoubtedly necessary. However, it's important to acknowledge that there's a possibility it could introduce disruptions in external code. To mitigate this potential impact, we're planning to conduct a thorough search across both public code repositories and internal code projects accessible to us. This search aims to identify instances where this fix might cause conflicts or complications. Based on our findings, we will make an informed decision about whether to integrate this fix into the upcoming v5 release or reserve it for inclusion in the subsequent major release, v6. For now this change will only effect version 6, and we might port it back to v5 at some point.
This pull request addresses a longstanding regression related to the unintended runtime leakage of imported symbols.
During the process of refactoring the internal symbol resolution code to achieve consistent handling of various symbols, an oversight occurred. This oversight caused the generated JavaScript runtime and the
.d.tsfiles to inadvertently expose imported symbols of the stylesheet.This situation is problematic because Stylable's assumption is that symbols of a stylesheet are only meant to be used if the stylesheet is imported into a JavaScript file. If it's not imported this way, it's assumed that the symbols' namespacing can't be connected to the DOM and can thus be removed as unnecessary code from the final output.
This fix is undoubtedly necessary. However, it's important to acknowledge that there's a possibility it could introduce disruptions in external code.
To mitigate this potential impact, we're planning to conduct a thorough search across both public code repositories and internal code projects accessible to us. This search aims to identify instances where this fix might cause conflicts or complications. Based on our findings, we will make an informed decision about whether to integrate this fix into the upcoming v5 release or reserve it for inclusion in the subsequent major release, v6.For now this change will only effect version 6, and we might port it back to v5 at some point.