libraries.yml version properties depend upon drupal core

+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']));
      }

See also: https://www.drupal.org/node/2274843/revisions/view/13464318/13535225 →

@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?

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.

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

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.

Rebased and removed the remainder of version: VERSION lines.

I have checked the above MR where all the version keys are removed and it works fine.
I also agree to @steven_jones opinion and @danchadwick 2nd point, set everything to version 1, and then every time the JS/CSS in a library changes, increment that number. we do not need to rely on cache, or updating the WEBFORM_VERSION with any extra processing.

liam morland → made their first commit to this issue’s fork.

Automatically closed - issue fixed for 2 weeks with no activity.