Why not have @opentok/client as a dependency?

[jedrichards]

With modern tooling, intelligent code splitting and caching incorporating @opentok/client into your bundle could be a more efficient approach than forcing an extra HTTP request and hoping the OT global is present in apps.

You could also ensure your library is always bundled with the correct version of @opentok/client, and avoid version mismatches.

It would simplify your documentation too, since you wouldn't have to worry about external script loading.

[jedrichards]

As I see it you have a few options:

Use npm normally

Add a @opentok/client as a normal dependency. And import it like import OT from @opentok/client, rather than relying on the OT global being present.

This will swell the bundle size, but you could make a note in the docs and suggest users use strategies like code splitting by route to optimize bundle loading. Many frameworks now do this sort of thing by default with no special configurations or effort required.

The explicit versioning mentioned above would be a big plus here.

Dynamic import

If it's not possible to change the architecture to the degree required to import the client idiomatically then an alternative would be to dynamically import the library instead. It's been possible to dynamically import modules at runtime with Webpack for a while now, e.g.

import('@opentok/client').then(() => {
  // Client is loaded and OT global is present
})

You could even make "preloading" @opentok/client not a responsibility of this library and instead document dynamic importing as a solution to be pushed into user land.