Active
Project:
Drupal core
Version:
main
Component:
asset library system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
22 Jul 2023 at 09:18 UTC
Updated:
18 Apr 2024 at 14:25 UTC
Jump to comment: Most recent
When LibraryDiscoveryParser find a library with no version specified, it sets it as -1. There's also a @todo to use a module version if that is set.
Add a constant, probably LibraryDiscoveryInterface::UNVERSIONED or something? so that we can document the magic -1 number.
We could also potentially expand the scope to resolve the @todo and add module version there when it's not set, or do that in a follow-up if it's tricky.
Comments
Comment #2
berdirSomewhat related to this, should we more strongly discourage or even automatically replace/ignore a library version of "VERSION"? core uses that and contrib copies that a lot (I see 227 results for that just in the contrib modules in my current project).
Or instead of removing and ignoring, we could possibly also make it work and get the module version in there.
I think there's an existing separate issue for that as well, but I think the way #3370828: Ensure that edge caches are busted on deployments for css/js aggregates was solved means it will become much more of an issue.
Comment #3
mxr576Is there a reason why
version === NULLshould not replaceversion === -1? -1 is definitely not a valid semver number... I admittedly did not spend time on understanding from the original issue why -1 was decided to be used.When I updated the related documentation page I made sure that -1 is not mentioned because it has to remain an internal logic if it stays https://www.drupal.org/node/2274843/revisions/view/13464318/13535225
Would be beneficial addressing that in the future, because there are always copy-paste-ppl out there who may not know (yet) what are they doing ;S