Exposing TypeOverrides from the library's root

[vitaly-t]

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

[brianc]

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?

[vitaly-t]

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.

[brianc]

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.

[gabegorelick]

It would be great to get this merged. @types/pg has had to add this path to their type definitions: DefinitelyTyped/DefinitelyTyped#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?

[mesqueeb]

@vitaly-t can you update this PR so the new esm index files also expose TypeOverrides.

@brianc this one could also get some love now that the esm index files are in! 🎉

[brianc]

this one could also get some love now that the esm index files are in!

definitely. I'll have to redo this since there's a merge conflict & its lacking tests, but its a very small change. I'll get a PR put up today & reference this one.

[brianc]

@mesqueeb - see new PR 😄

[brianc]

closed in #3433