- Issue created by @DanChadwick
- ππΊHungary mxr576 Hungary
+1 on this
For a start, I would just remove the "version" declaration which would lead to file content hashing in
\Drupal\Core\Asset\AssetGroupSetHashTrait::generateHash()
because that would default back to-1
.// If the version is set to -1, this means there is no version in the // library definition. To ensure unique hashes when unversioned files // change, replace the version with a hash of the file contents. if ($asset['version'] === -1) { $normalized['asset_group']['items'][$key]['version'] = hash('xxh64', file_get_contents($asset['data'])); }
- ππΊHungary mxr576 Hungary
- Status changed to Needs review
5 months ago 10:45am 23 July 2024 - π¬π§United Kingdom steven jones
@mxr576 Thanks for this.
I'm going to mark this as needs work, since webform has lots of submodules with libraries too, and the MR doesn't adjust those.
I also wonder if it would be a suitable approach for webform to use its own constant in the files, like
WEBFORM_VERSION
and then at runtime do a library alter to swap out that string for the actual webform version, if one can be determined? We don't want all of contrib doing that, but maybe webform could? - Status changed to Needs work
5 months ago 9:45am 26 July 2024 - π¬π§United Kingdom steven jones
More generally, I like the proposed resolution, we might as well set everything to version 1, and then every time the JS/CSS in a library changes, increment that number. There's no need for it to be semver or anything exciting tbh.
- π¬π§United Kingdom steven jones
And...if you don't/can't/won't change the contrib versions, we're looking to get a workaround into our helper module that should 'fix' all contrib:
https://www.drupal.org/project/cm_tools/issues/3464016 β¨ Fix contrib using VERSION in library definitions Needs review - πΊπΈUnited States DanChadwick
This is sort of a core problem thrust upon contrib. Once could argue that VERSION in a module or theme should be interpreted as the module's version. So I think we should set aside WEBFORM_VERSION as scope creep. That leaves two good options:
1. Remove all the version properties and rely on caching.
Pro: Super simple.
Con: a tiny bit of extra CPU time when the caches re being rebuild. I assume (without actually checking) that this is very infrequent.2. Add versions and be sure to update them during commit, checking for conflicts.
Pro: More efficient at cache rebuild time
Con: Requires developers to remember. Possible conflicts if the version is bumped twice before a conflicting merge is made, resulting in re-using an older version number.I propose we move forward with 1, including removal of all inappropriate versions in webform and all its submodules.
- First commit to issue fork.
- π§πͺBelgium dieterholvoet Brussels
Rebased and removed the remainder of
version: VERSION
lines.