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
{{ message }}
Repository navigation
Remove internal uses of "namespace barrel" modules, untangle repo #51443
In #51387, I introduced the concept of the "namespace barrel" modules, located at **/_namespaces/*.ts.
While this does help us transition to modules, internally, this is a gross hack and makes it hard for us to start splitting the codebase up, export just the parser, etc.
We should be trying to remove internal uses of these files and use direct imports, leaving these files for our public API surface only.
Low hanging fruit for untangling: typeHasCallOrConstructSignatures is defined as a helper, but is then used by the checker. This should be flipped and that's one cycle down.
Activity
jakebailey commentedon Nov 8, 2022
Low hanging fruit for untangling:
typeHasCallOrConstructSignaturesis defined as a helper, but is then used by the checker. This should be flipped and that's one cycle down.a-tarasyuk commentedon Nov 11, 2022
Jake Bailey (@jakebailey) Do you mean it's better to use
instead of
?
Or do you mean that we need to avoid
import * as ts from "./_namespaces/ts";?jakebailey commentedon Nov 11, 2022
Yes, the first one, not the last two. Reasons being:
core.tsshould not be depending onscanner.ts. That code should be moved.jakebailey commentedon Aug 25, 2026
We are now Go, so this isn't happening