Links to Swiper CSS and JS point to incorrect version

Ooops sorry, accidentally made the changes in the 1.0 branch, replicated in correct issue branch.

Hi,

The module uses unpkg.com/swiper@11/ instead of the specific versions proposed in the description. If we add the proposed change as it is, then there will be a version mismatch. Is there a reason why you didn't just update the number 8 to 11 without changing the domains?

Thank you!

If I remember right, the unpkg links didn't work with version 11 (no idea why) so I grabbed links from the official Swiper docs for the CDN. My ultimate goal was to just get the version working as it was being really buggy with the incorrect version.

So yeah, I selfishly didn't consider those with it already setup, but considering it was really buggy, they would have needed to change the local file in their library anyway as the module doesn't do that part.

I see and it's understandable. Makes sense.
But now that the links are working, I think we should have the same in both places: libraries and help text.

Agreed, would it also be sensible to have the links for version 11 as:

https://unpkg.com/swiper@latest/swiper-bundle.min.css

Or does it need to be fixed to a specific known working version?

I think major versions should be updated by us (my opinion as a co-maintainer), it's a bit risky to have them change on the fly without prior testing. I'll have the maintainer confirm as well.

I agree that we shouldn't run new version as they come, that was after all the original reason for not defining url with @latest, or the other token. So let's keep it as it is for now.
In fact, I believe it is worth considering implementation of https://asset-packagist.org/ or similar, at least as an approach.

Sounds good, thanks for confirming.
In this case, let's solve the issue at hand by matching the values from libraries. A separate issue can be open for the library management if needed.
So, the values in the MR should match the values in the libraries definitions.

There's been some talk this year about asset-packagist reliability:

See:
https://www.sitback.com.au/insights/article/working-with-javascript-in-d...
& https://github.com/darvanen/drupal-js/tree/main

While I'm not really loving the proposed way that works, it may be worth chasing the rabbit and seeing if there is any more consensus on external JS inclusion methods?!?

nk_ → closed merge request !7