Hi, I’m using lib-jitsi-meet in production application for few years already and I find installation of the library a little bit cumbersome. For some time we had to simply download the dist files of particular version and serve as as static assets, in an era of npm packages - that’s a bit inconvinient from the upgradability perspective, to ease this process - we introduced a script that cloned the given revision, built it and copied dist files to our vendor folder, then ensured we get around long TTL of our static files cache - worked great. Now I see that “jitsi-meet” links the library in package.json using a github link to an archive of a release and it looks like the lib finally depends on strophe from npm. I thought that I’ll give it a try and maybe can finally install the lib via npm and import it as a module…
And here comes the list of issues:
The package.json doesn’t have “exports” field, nor the “type”: “module” in it
Fixing above revealed however that the entire /dist/esm folder is a mashup of ESM and CJS
So it looks like the way to use the lib, is to still copy dist files from dist/umd and load globally…
I’m creating this topic, because I’m curious what are the reasons that:
a) The lib-jitsi-meet isn’t versioned (somewhat is, but “version” field in package.json still says 0.0.0)
b) It’s not published on NPM
c) Its esm build isn’t a consistent ESM module, but a mix of CJS and ESM
d) Still requires jQuery/$ at window, rather than relying on imported jQuery
Wouldn’t it be nice to simplify the development experience and allow devs to the following?
npm install --save lib-jitsi-meet@1486.0.0
And then:
import JitsiMeetJS from "lib-jitsi-meet";
// or
import { createLocalTracks, mediaDevices } from "lib-jitsi-meet";
It’s not a mashup. We create 2 distributions: UMD for browsers and ESM for those using ESM modules, see the link above.
We make use of both of them: the web app uses the UMD target and the mobile apps suign React Native use the ESM target.
That is exactly the same as before we started making the 2 bundles, and it’s how we consume it ourselves.
Because we don’t make standalone LJM releases.
This one is harder to understand. Jitsi Meet components are released “in tandem”. The compatibility of LJM with a given version of the backend components is not a guarantee. Thus we don’t want to have users’ meetings break because they’d neglect to update the dependency. Thus we recommend sourcing the library directly from our deployment (or their own).
We make tarball releases on GH for convenience, but if you choose to use them you are on your own.
There are some requires in LJM still, PRs removing those are welcome.
This is because the Jitsi Meet app also uses it and we wanted to save having 2 copies of it. Now, in the grand scheme of things it’s not that big of a deal so I’d say a PR that embeds jQuery would be acceptable. Completely removing it is a goal we have, but it’s quite a tall order.
You were not missing anything, it’s just complicated due to what I mentioned above: LJM gets released in tandem with jicofo and the JVB.
Thanks for the quick response @saghul, appreciate it
It looks like the “module” field that is currently set might only be used by the bundlers, and is ignored by NodeJS according to the documentation Modules: Packages | Node.js v16.16.0 Documentation (Same for v14, v15, v17 and v18)
So it might make sense to add “main” field in the package.json, this way it should allow importing everything as expected. (I tested this already releasing the package under private namespace).
I meant that inside dist/esm/.. we can find both export default ... and module.exports = .... Though ESM supports both versions, so it seems to be not big of a deal.
I see. Though from technical standpoint - either creating tarball on GH or publishing in github packages doesn’t differ much besides the fact that doing the npm publish would force having a correct version set in the package, and not having to rely on a link to archive but simply a version number.
I guess that’s also matter of preference, but given this is a public library it would be convenient to install it like any other package and after upgrading JVB on the server just bump the version in package.json to one matching the other one.
Have you tested this with the mobile build? One such bundler might be Metro…
Ah right, there are indeed some unmigrated imports. I expect those to be eventually gone.
There is a huge difference. You are correct on the technical level, but publishing a package contains the implied assumption it’s ok to use it, versus the current case, where we made it explicitly obscure to raise questions such as this one, with the answer being: don’t.
