Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Currently the definition of libraries in the leaflet module use the core VERSION string as the value of the version key.
This is incorrect, since only core should be using this version number, since it'll get replaced out with the current core version number, and not the leaflet version number etc.
This can cause issues when updating the module, and finding that the aggregates of JS files are not invalidated correctly, or that old versions of the code are served up by CDNs etc. because the URL has not changed.
Steps to reproduce
Update the leaflet module when it makes changes to the JavaScript provided by one of the libraries defined with VERSION as the version.
Proposed resolution
Remove the VERSION string, and either:
- Use a simple version number that'll get incremented with further changes.
- Remove it entirely, and core will hash the contents of the file to generate a version 'number'.
Remaining tasks
Decide on an approach.
User interface changes
None.
API changes
The URLs for the JS files might change, which could be tentatively called an API change, but not really.
Data model changes
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | leaflet-use-branch-versioning-for-custom-libraries-3467557-12.patch | 2.41 KB | itamair |
Issue fork leaflet-3467557
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
steven jones commentedComment #5
prem suthar commentedI have Remove the VERSION string in libraries definition and Raised the Mr Please review.
Comment #6
steven jones commentedLooks good to me, thanks.
Note that this will leave a mix of some library definitions without a version number, and some with, because leaflet seems to be declaring lots of versions like:
1.xetc.Anyway, this is an improvement, maybe we need to see if a module maintainer would like to remove all the version numbers, or start using them an incrementing them when something in a library file changes.
Comment #7
itamair commentedThanks a lot Steven ... that all makes sense,
and also according to this article from Chromatic: https://chromatichq.com/insights/drupal-libraries-version/
With the new attached patch I comply with your suggestion and fix all the not Remote libraries versioning, aligning them with the current dev branch.
Please QA and Review this attached Patch (which is more accurate than the provided MR !43), if you have some more time on this ...
Comment #8
steven jones commented@itamair thanks. I think you've missed the
leaflet-drupallibrary from your patch though?https://git.drupalcode.org/project/leaflet/-/blob/51a59100f864a16fb28e0b...
If you are wanting to go with option 1 and include the simple version number, are you going to increment it in the definitions when you make changes to the JS/CSS files?
Comment #9
itamair commentedThanks Steven ... yes right you are, I missed the leaflet-drupal library version fix/update,
thus here it is a new attached patch, that includes also it.
For what regards the naming approach I am taking inspiration from the Geolocation module that is using as 'version' the same dev branch name:
https://git.drupalcode.org/project/geolocation/-/blob/8.x-3.x/geolocatio...
This might have the advantage not to need an update of the version for each new release of the module, and of the specific js/css release, and I am assuming it will behave similarly to the option 2 that you mentioned, and the js/css caching system will look for hashed changes in each library? Or would I be too much optimistic on this?
What would be the behaviour in case of this naming simply based on the module release dev branch?
Comment #10
steven jones commented@itamair sadly, there's no magic in Drupal around the handling of these strings. So, no it's not going to do anything special with
10.1.xor whatever.Either:
Comment #11
itamair commentedthanks @steven ... for your detailed and clear explanation.
I would go for the simplest solution, also from the maintenance effort side (that is already quite demanding an all this geofield stack modules), hence simply remove all the versioning tagging and management for libraries that are not remote/external ones,
considering that you don't highlights any caching side effect doing this, but rather a proper and automatic handling from the PHP cashing/cashing system ... isn't it.
Please, give me a final green flag on this new attached patch, or let me know what might be stil missing.
(and super thanks again for your guidance ...)
Comment #12
itamair commentedSorry, new final patch, that re-adds the leaflet-geoman library version tag (removed by mistake) ...
Comment #13
steven jones commented@itamair yeah, this looks great to me now. Thanks!
Comment #15
itamair commentedGreat! New leaflet 10.2.24 just released with all this ...