Interesting that when I first opened this PR, it generated baselines in tests/baselines/reference/api/*.d.ts, and after rebasing against master, the change no longer affects those baselines. Just want to make sure that's intended.

tsbuild API is internal right now and we would want to make sure to expose it right way after reworking on it.
cc: @RyanCavanaugh @DanielRosenwasser

It no longer affects the API baselines because the entire tsbuild namespace got marked @internal because we didn't intend to expose it, I believe.

👍🏽 Makes sense. In regard to the conversation in TypeStrong/ts-loader#815
TypeStrong/ts-loader#815 (comment):

[Me]: would the team consider exporting this so we don’t have to duplicate the logic?
[@RyanCavanaugh]: certainly.

Does that still stand with all the tsbuild stuff being marked internal? Other tsbuild functions are still exported, right? (Some of the others may be needed for the proposed second phase of ts-loader support, building upstream projects.)

On the other hand, if all these APIs are totally internal and subject to change in patch releases, that makes them a bit hard to rely on in a package like ts-loader. @johnnyreilly thoughts on this?

I'd much rather rely on TypeScript APIs than duplicate logic in ts-loader if possible. That said, we'll try and be pragmatic; if it's a simple function that's unlikely to change then it's not the end of the world if we duplicate. But that's very much second preference.

We need to make a decision for ts-loader (TypeStrong/ts-loader#815) in the next couple days, so any update here from the team would be greatly appreciated. Thanks!

We are still working on api to use project references and anything from tsbuild wont be available as api till that work is complete.
cc:: @RyanCavanaugh

Ok, thanks for the update. Feel free to close this if it doesn't make sense.