Consider composer-merge-plugin or composer-installers-extender for 3rd party libraries

So I like this idea, and I did explore using composer.libraries.json during development, but one thing I struggled with was the fact that the upstream releases don't include a compiled library.

I'm not too familiar with the composer libraries workflow here, but it looks like it would need to include a npm compile step (not sure if this is possible) or ONLY pull the library from a CDN. Unpkg is a good candidate and they have recent builds we could use.

I'm not wild about packaging partytown.js with the rest of the module, but right now it feels like the most stable option available.

Do you have some ideas about how to solve this?

The only other option I can see is to work with the upstream maintainers to get a lib build included in the next release.

I've filed an issue on the upstream project because I think this would probably be a good improvement, anyway. Fingers crossed!

Oh, there is no built version of the library. Yeah, that's problematic. I guess that's why there are a bunch of npm packages for various frameworks to use partytown.

I can't think of any thing good that doesn't also require a bunch of work

- gitlab job that builds and makes an extra commit.
- manually building the source and committing it based on a package.json (like a ckeditor plugin)

Yeah, both of those are good. Thanks for brainstorming with me here.

So it looks like we'd either be doing the build manually or getting gitlab to do it for us. I think both are valid options. My leaning is toward the manual, ckedit-like, route since that is already an accepted packaging practice in Drupal.

I'll play around with this a little bit and see what I can make.

https://partytown.qwik.dev/distribution/ talks about the origin/scope requirements...

The lib directory contains the static files that should be hosted from the same origin as the website. Hosting from the same origin is a requirement of the service worker scope.

The library is licensed as MIT so it can be included in the module repo on Drupal.org from a licensing perspective, but the required build step and origin issues with a CDN make this a little different than most js dependencies in Drupal modules.

Doesn't the option to change the path in https://git.drupalcode.org/project/partytown_drupal/-/blob/1.0.x/src/For... eliminate any lock in? You wouldn't be stuck with a specific version of js just because that's what the module maintainer included. Since we know this is beta and has had 82 releases since July of 2022, if you want to update before the module you could still do that. I could see adding this to a theme build.

Not really sure what else could be done to improve this.

So CDNs are out based on the same origin policy, which leaves us with bundling it in the module using composer or npm, manually or automatically.

To kreynen's point, there aren't exactly a lot of releases, and the burden of packaging new releases would only fall on me at the moment.

The automated aspect of letting a package manager do this would be great, but that may not be relevant if we're looking at a handful of maintanence releases in the next year or so.

I think having a physical receipt in the form of a lockfile or a libraries.json or something else is a good practice, so its clear what we're shipping.

I think a good solution in the short term is to package it with npm and later on using composer if we can swing it.

Thoughts?