brianc
Exposing TypeOverrides from the library's root
TypeOverrides is too important not to expose it. It should be available from the root.
It is essential part of custom type parsing, for which singleton types is exposed, while TypeOverrides is not.
One of the big issues the current implementation has - impossible to properly declare the type in TypeScript, since it is a class, which we have to use as any interface instead (it's awkward).
Related: #1838, #2363
Thanks for this - this seems reasonable, but could you write some tests which will both prevent this from regressing & also demonstrate how this would be useful?
It's just type exposure through variable, why do you need tests for that?
And as for how this is help full, I explained it from start:
One of the big issues the current implementation has - impossible to properly declare the type in TypeScript, since it is a class, which we have to use as any interface instead (it's awkward).
i.e. the lack of the type makes it very awkward to use it from TypeScript, with direct file inclusion and all. Especially because that extension is a class, and needs proper TypeScript class declaration.
It's just type exposure through variable, why do you need tests for that?
Otherwise in the future it might get unexposed & then we wouldn't know we're breaking anything until we release a version w/o it exposed. So just a simple check to make sure it's there is fine.
It would be great to get this merged. @types/pg has had to add this path to their type definitions: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/51175
but could you write some tests which will both prevent this from regressing & also demonstrate how this would be useful
Are there existing tests for exports that this can be added to?
