An often forgotten nit pik is the version: tag in libraries files which will be placed on the end of the library path to tell browser cache if it is the same or not.
Problem/Motivation
The "version:" tags in libraries.yml files keep libraries' files cached in browsers per module version, which makes only sense if updated with the module version. Otherwise: This can cause fixed bugs to be unresolved when updating this module separate from a Drupal core update. Sadly there is no version: VERSION for reference to module version, only for core which makes no sense here at all. For regarding core issue please follow: #2205027: VERSION in library declarations does not work for contributed/custom modules
Proposed resolution
Remove all "version: 8xx" lines from the libraries.yml files or update them with the module version. Caching these static files should not be needed in all cases whatsoever, but if for some reason this is wanted behavior, then the version should at least be set to something relevant to the library definition instead of a Drupal core version or even worse (like at the moment) to an older module version.
Committed solution: updated version tag to 4.x
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 3426265-2-Update_version_tag_in_libraries_yml_file.patch | 504 bytes | dqd |
Issue fork conditional_fields-3426265
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:
- 3426265-update-version-tag
changes, plain diff MR !42
Comments
Comment #3
dqdComment #4
dqdComment #7
dqdComment #9
dqd@Mohd Sahzad: Please check the issues before forking. If there is already a patch, please do not copy patches and create merge requests without necessity or request/plea to save resources and clutter on D.O. and Gitlab. Thanks for understanding.
Note for backtrace: Original patch committed to 4.x dev without RTBC (minor change).
Comment #10
dqdComment #11
dqd