Repository navigation
Remove internal uses of "namespace barrel" modules, untangle repo #51443
Description
Activity
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.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
Jake Bailey (@jakebailey) Do you mean it's better to use
// @filename: core.ts import { Debug } from "./debug"; import { __String, CharacterCodes, Queue, TextSpan, UnderscoreEscapedMap } from "./types"; import { Comparer, Comparison, EqualityComparer, MapLike, Push, SortedArray, SortedReadonlyArray } from "./corePublic"; import { isWhiteSpaceLike } from "./scanner"; ....
instead of
// @filename: core.ts import { __String, CharacterCodes, Comparer, Comparison, Debug, EqualityComparer, isWhiteSpaceLike, MapLike, Push, Queue, SortedArray, SortedReadonlyArray, TextSpan, UnderscoreEscapedMap, } from "./_namespaces/ts"; ...
?
Or do you mean that we need to avoid
import * as ts from "./_namespaces/ts";?Yes, the first one, not the last two. Reasons being:
- This is how we would have written things if we had been modules from the start.
- By going through the barrels, we make cycles harder to resolve. For example,
core.tsshould not be depending onscanner.ts. That code should be moved.
We are now Go, so this isn't happening
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.