User installs symfony/ux-autocomplete. Flex adds tom-select at version 2.2.3 to importmap.php
3 months later, user upgrades symfony/ux-autocomplete. The new version now requires tom-select at ^2.5.
If we do nothing, the user's tom-select is out of date and the user won't even know about it. The ^2.5 constraint is defined in the symfony/ux-autocompletepackage.json file, but nothing enforces that or notifies the user.
With this small change, during a composer update/require, we look at the dependencies of all UX packages and compare them against the version in importmap.php. If they do not match, the package is upgraded to a version that matches.
We're not creating a fully-fledge package management by any means, but we don't need to. With a few notifications and things like this, we can keep the user's dependencies in sync with each other.
Unrelated: don't forget about that really cool other PR #978 ;)
Hi!
The scenario:
symfony/ux-autocomplete
. Flex addstom-select
at version2.2.3
toimportmap.php
symfony/ux-autocomplete
. The new version now requirestom-select
at^2.5
.If we do nothing, the user's
tom-select
is out of date and the user won't even know about it. The^2.5
constraint is defined in thesymfony/ux-autocomplete
package.json file, but nothing enforces that or notifies the user.With this small change, during a composer update/require, we look at the dependencies of all UX packages and compare them against the version in
importmap.php
. If they do not match, the package is upgraded to a version that matches.We're not creating a fully-fledge package management by any means, but we don't need to. With a few notifications and things like this, we can keep the user's dependencies in sync with each other.
Unrelated: don't forget about that really cool other PR #978 ;)
Cheers!