Published `.d.ts` files don't type-check
If you try to consume the ecmarkup package via the API, it will fail to type-check because Clause is marked /* @internal */...
https://github.com/tc39/ecmarkup/blob/05d05f71e1bc8cf151da65d34e9105eff3e7d465/src/Clause.ts#L26-L27
but maybeAddClauseToEffectWorklist still uses the non-existent default export publicly.
https://github.com/tc39/ecmarkup/blob/05d05f71e1bc8cf151da65d34e9105eff3e7d465/src/Spec.ts#L254-L258
This results in the error:
node_modules/ecmarkup/lib/Spec.d.ts:49:84 - error TS2709: Cannot use namespace 'Clause' as a type.
Should maybeAddClauseToEffectWorklist be marked internal as well?
@DanielRosenwasser I can remove /* @internal */ from Clause, but ideally I'd like to figure out how to prevent this category of issue in the future - is there a way I can write a test which ensures the published TS definitions typecheck? I didn't realize TS would let me publish invalid .d.ts files from a well-typed project, given that it's the thing generating them in the first place...
/* @internal */ is a long-standing "undocumented" feature that I've wanted to redo since 2015 into something actually baked into the language. It was a bit of an expert-level workaround for trimming things from your public API and unfortunately hasn't received much attention since TS 1.0.