Module violates GDPR compliance through requring the js_cookie library via cdn

Make sure, that npm-asset/js_cookie points to the correct library!

Which one should be used here?

• https://github.com/js-cookie/js-cookie
• https://github.com/delfimov/JS-Cookie (this is the one where npm-asset/js_cookie points to)

I suggested in ✨ Support local library file Active to pragmatically include the library in the module, making life easier for the end user, and got positive feedback.

@grevil:

@ressa, that would probably be the best approach for the end user I agree! But we would need to manually update the js library once in a while.

Although I am quite confused, as to why the npm-asset package and the gihub latest github release are version-vise out of sync! (3.0.5 vs. 1.0.0), seems like they point to two different repositiories. I'll comment that in the parent issue.

It's great that you are open for this suggestion, thanks!

Since JavaScript Cookie Version 3 was released in July 2021, more than three years ago, there were just a few NPM-related releases ... So it's updated quite rarely.

I think that's a pretty strong argument for bundling the library inside the module.

Then, not only would the CDN/GDPR-issues be solved, installation and maintenance of the module would also be much easier for the end user. Especially if the package versions are out of sync. This would be yet another argument for taking the burden of figuring this out off the shoulders of the end users.

What do you think?

I'd agree with that!

Furthermore, there seems to be no (correct) asset packagist composer package (other than the one created by @herved).

Let's see, what @dave reid has to say about this.

Fantastic, thanks @grevil!

I just added tag GDPR to #3390616 and created a new MR with the approach of composer.libraries.yml ( like webforms does → ) and added requirements also.

Maybe this issue can be closes as duplicate?

BTW: For the Bill of Materials software, an installation via Composer is preferable because the composer.lock files can then provide complete information about the software used, known security vulnerabilities and available updates. Therefore, a solution via Composer would be the better way than including the library file.

We can close this in favor of ✨ Support local library file Active , but I am unsure if I like this approach...

Apart from "webform" not many modules use this approach and it requires an additional composer plugin. But we can discuss this in the other issue.

@grevil Fully agree that a standardized approach would be great here! Many have worked with asset-packagist until there was confusion about the seriousness of the source. Otherwise, you could simply include the library in composer.json via https://asset-packagist.org/package/npm-asset/js-cookie. Unfortunately, there is no composer source, so a separate repo entry is required.

But we can simply include in the documentation how this can be manually integrated into the own composer.json, then you can save yourself the merge plugin and don't get packages installed without being asked.

@jan kellermann, nice! Last time I checked, I couldn't find the right js-cookie package on asset packagist! I agree let's document that as an alternate option!