Export TS types in a separate entry point via 'mediasoup-client/types'

[ibc]

Details

The idea is that, instead of exporting types like this:

import { types as mediasoupClientTypes } from 'mediasoup-client';

We import them this way:

import types as mediasoupClientTypes from 'mediasoup-client/types';

I've also removed "main" and "types" fields in package.json since they are replaced by the new "exports" field.

Related documentation

• "TypeScript and NPM package.json exports the 2024 way": https://www.kravchyk.com/typescript-npm-package-json-exports/

TODO 1

I've briefly tested this and it looks like for this to work, the parent application must have in its tsconfig.json:

"module": "nodenext",
"moduleResolution": "nodenext",

Is this ok? Any other implications?

TODO 2

Should we stop exporting types from 'mediasoup-client' and instead force applications to import them from 'mediasoup-client/types'?

TODO 3

We should export HandlerInterface type so applications do not need to do this ugly thing:

import { HandlerFactory as MediasoupClientHandlerFactory } from 'mediasoup-client/lib/handlers/HandlerInterface';

[jmillan]

I've briefly tested this and it looks like for this to work, the parent application must have in its tsconfig.json:

"module": "nodenext", "moduleResolution": "nodenext",

If the application does not set such values (for any reason they may have), can it still use the old way of importing the types?

[ibc]

I am not sure. I've tried to test using mediasoup-demo client app but it's SUPER OLD and doesn't even use TypeScript so we are lost here.

[ibc]

This is ready for review.

[ibc]

NOTE: These changes have been reverted in 3.8.1. The world is not ready for these things yet.

[Fabioni]

NOTE: These changes have been reverted in 3.8.1. The world is not ready for these things yet.

What's the reason?

[ibc]

NOTE: These changes have been reverted in 3.8.1. The world is not ready for these things yet.

What's the reason?

The reason is that the syntax of the "exports" field in package.json is not universally defined. NPM docs refer to the documentation of "exports" in package.json of Node projects where the value of each item in "exports" is basically a path to the corresponding file (it doesn't cover TypeScript .d.ts files at all), while in webpack the value can be an object with "import", "require", "types" (pointing to the .d.ts file with TypeScript definitions). Then ts-jest doesn't read the "types" field so it throws an error because "types not found", etc. Then ts-jest also fails if an entry in "exports" points to a file that exports a const, etc etc. I investigated and indeed it's a know ts-jest issue.

It's a complete nightmare and I already spent too much time trying to deal with it.