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[bot]]

🦋 Changeset detected

Latest commit: 65ff5f52eb196fe62bc063255e07c39b939e2c2e

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 :see_no_evil: 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 :smile: (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)