I should note - I may be missing something here as I’m new to lib-jitsi-meet, so apologies if that’s the case. I wouldn’t think that including them in the bundled file would cause any compatibility issues as the libraries aren’t changing, you’re just pulling them in yourself at build-time instead of relying on the user bringing them in. I understand that it compatibility with the backend is a priority, but I don’t quite understand why a module bundler is being used but libraries that don’t look like they’re going to change much (jQuery, strophe) aren’t added in too. ie the location of the meet lib in the deployed docker instance /* global JitsiMeetJS */ The only tricky thing that I have found is that jitsi depends on a global jquery… so I need to import that in (this is the only lib in our project that uses jquery). I think this actually works better because then the deployment of jitsi and the lib that uses it always matches up. We actually deploy Jitsi (using the docker lib) and manually import the script from docker at runtime. Just thought I’d share how I do our implementation.
We actually use a 100% custom UI (using React) over lib-jitsi-meet. Interested to hear your thoughts on this. This all can be solved by the user including tags in their html, as you recommend, or possibly by using webpack’s ProvidePlugin, but it seems like it would be far nicer to try to do as much as possible when packaging the module in the first place. Is there a reason that the choice was made to require these modules globally, rather than just importing them whenever they’re needed? From looking through the codebase it looks like the same goes for jQuery. At this point it’s clear that the strophe and strophe-plugins modules aren’t included in the file that webpack builds, even though they are listed as project dependencies. Now, however, we get a ReferenceError: Strophe is not defined.Īdding import strophe does resolve this, however we then get Missing strophe-plugins (disco and caps plugins are required)!. then import JitsiMeetJS from 'lib-jitsi-meet' does in fact import JitsiMeetJS as expected.
#Lib jitsi meet update#
If we update the "main" property of the package.json to be. index.js file, rather than the built (and transpiled) file created by webpack.
#Lib jitsi meet install#
Navigating to /node_modules/lib-jitsi-meet and running npm install manually does install these devDependencies and run the postinstall script successfully, creating and .Īt this point, trying to import JitsiMeetJS from 'lib-jitsi-meet' creates errors as the "main" property of the package.json references the.
Doing that, however, seems to do three things. Obviously the package isn’t currently published to npm, but that’s not an issue as we can install directly from this repo. It would be nice if we could simply npm install lib-jitsi-meet within a project and then just import JitsiMeetJS from 'lib-jitsi-meet', however this currently doesn’t seem to be possible. Is there a reason that this package isn’t really optimized for being installed through npm? I’m trying to integrate this into a React app and I’m having a bit of a hard time getting everything up and running. Apologies if this has been discussed already, but I can’t find any other conversations on this topic.
0 kommentar(er)
