feat: js module distribution

[holzgeist]

This PR enables the bundling of this library as standalone package, e.g. for usage in the web part of livekit/client-sdk-flutter

[changeset-bot]

🦋 Changeset detected

Latest commit: edb35e7

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@livekit/track-processors	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[lukasIO]

thanks for the suggestion. I don't think removing livekit-client as a peer dependency altogether is the right option here though.

The flutter web lib is not type compatible with the JS version.

[holzgeist]

Thanks for the review, I removed livekit-client during development, but re-added it during cleanup. It seems like I accidentally removed it during rebasing/merging

The types are compatible enough for some basic wiring. I'm currently in the process of cleaning up my video background plugin: https://github.com/holzgeist/flutter-livekit-background-effects/tree/main/livekit_background_effects_web

[lukasIO]

I see, I had another look at the current implementation and the package is already using tsup for bundling.

I'm not sure what exactly your change is proposing. What exactly is missing from the bundle today for it to work for your use case ?

[holzgeist]

That's because I have very little idea about javascript bundling 🙈
I didn't know that tsup is a bundling tool too

The output file via tsup didn't run in the browser, so I assumed it was used for something different.

I'll try to play with tsup options tomorrow, maybe I'll succeed 😄 (e.g. a quick search showed the unused option platform which defaults to node, but has a browser variant..)

[lukasIO]

ah, I see what you mean. Yeah, for this we'll likely need to create single file build. Currently tsup sets the splitting option to true, which will likely fail for browser imports.
But even with that fix I'm not sure the internals here can properly access livekit-client dependencies.

when you say

The output file via tsup didn't run in the browser,

how are you currently importing the module?

[holzgeist]

It looks like the iife output option combined with globalName does what I want. splitting only affects esm anyway, so it can stay like it is for my use case.

I import the script via a (programatically added) tag like this: <script src="URL" />, inspired by this flutter plugin: https://github.com/florent37/flutter_web_import_js_library

[lukasIO]

why wouldn't you use a dynamic import for the esm version?

[holzgeist]

according to the meme story in the js import library I linked above and my own tries, it's not (yet?) possible to dynamically import javascript from dart code, even when compiling for web only

[holzgeist]

Update: I might have found something (using your "dynamic import" wording to start looking for something more specific): https://api.dart.dev/dart-js_interop/importModule.html
I'll play with this (might take a while though, vacation is coming up)

[1egoman]

I'm not sure the status of this, @holzgeist were you able to get your alternate solution to work? If not and you still are hoping this could get merged, feel free to post a message here and I'll give what you have here a shot locally.

Maybe a helpful note - if you are trying to integrate this package with the umd build of livekit-client (which is being built by rollup), then I think window.livekitClient (this is defined here, note that packageJson.name is livekit-client) should be set in a browser context and is where this package would need to look to get the loaded version of livekit-client.

[holzgeist]

Hi @1egoman

I tried with the importModule function, but I failed with the livekit-client imports as you kind of predicted in your note.

The thing is that I don't use the umd build of the javascript sdk, but the web build from the flutter sdk. It is close enough to get it to work with manual glue code. (EDIT: I just saw that I mentioned that earlier already and that this is not a supported use case)

The solution in this PR works without issues (except a considerable larger compiled file because apparently the livekit js sdk is included in the result)