Remove FlowNodes and FlowFlags from public API#58036
Remove FlowNodes and FlowFlags from public API#58036jakebailey merged 2 commits intomicrosoft:mainfrom
Conversation
typescript-bot
added
Author: Team
For Uncommitted Bug
|
Looks like you're introducing a change to the public API surface area. If this includes breaking changes, please document them on our wiki's API Breaking Changes page. Also, please make sure @DanielRosenwasser and @RyanCavanaugh are aware of the changes, just as a heads up. |
|
I haven't been able to search properly for named imports. |
|
@dsherret I know that the flow node viewer was a recent and amazing addition to ts-ast-viewer; is a PR like this problematic for you? My impression is that in order to access the info, it already must reach into the internals, so it doesn't seem too far off to also need to do something special here for the types. We have other PRs in progress that will change the flow node API in a breaking way, so I suspect that the viewer will need to be updated in various ways anyway (and probably wasn't consistent in older releases either). |
|
That's fine. I'll deal with whatever happens 😄 |
Real 10x dev right here 😉 |
7 participants
These types are not referenced anywhere in our public API. #57977 modifies the flow nodes, but notes that the change is necessarily breaking.
However, these types are not even used in our public API. To be able use them, you'd already need to be using TS internals to poke at properties that were marked
@internal. This PR marks them as internal, and you can see that nothing breaks in the output declaration files.This will break https://github.com/dsherret/ts-ast-viewer/blob/74d0ba30e8bce861279a79e8f7d09634be9034d6/src/components/FlowNodeGraph.tsx at compile time, but #57977 and other changes like it will break it at runtime too. Given one already has to poke at internals, I feel like they should need internals to even have the types too...