Feature: Use api-extractor when generating the .d.ts files for distribution

[etrepum]

It's easy to make a mistake that will export an internal type. TypeScript doesn't seem to have any options to roll-up or inline types, but they do suggest using api-extractor in the stripInternal docs.

I have a hotfix up in #5920 to address #5918, this would be the better long-term solution.

tsup might be worth looking into as an alternative as well

[StyleT]

Short summary here of my research done in #5920:

• tsup doesn't work well because:
  • It repeats the copyright header a lot (once per source file that was rolled up)
  • It will bring in possibly unwanted global declarations, like this one (see above)
  • It fails to compile some packages as it aims esnext target w/o ability to override it https://github.com/egoist/tsup/blob/00188a0dc848c48fac45de245d1e021f370a84a3/src/rollup.ts#L147
• dts-bundle-generator is painfully slow and requires excessive configuration as it doesn't works same was as tsc
• api-extractor fails to figure out types for vars where we do destruction (known issue)
• rollup-plugin-ts requires rollup 3.x+ and has same issues as tsup except last one

[StyleT]

So likely some custom solution (probably based on rollup-plugin-ts) needed here

[etrepum]

Is tsc's hardcoded esnext target a problem in our situation? I don't recall running into any issue with it when I prototyped it locally, but invoking tsup for each package is very much noticeably slower running tsc over the whole repository (tsup for even a single package seemed slower than the whole-repo tsc). Fixing up the output is not that big of a deal so long as we are certain about what to remove.

Trying rollup-plugin-ts sounds like a pretty good idea though, especially if it can be combined with the existing rollup usage which would hopefully be more performant.

[StyleT]

Yeah, I got TS errors as ESNext is more strict comparing to the target lexical uses now.
Not all packages had them, but lexical did