aboutsummaryrefslogtreecommitdiffhomepage
path: root/crates/shirabe-external-packages
diff options
context:
space:
mode:
authornsfisis <nsfisis@gmail.com>2026-07-24 20:22:47 +0900
committernsfisis <nsfisis@gmail.com>2026-07-24 20:22:47 +0900
commitdacc1cb0d7d1397701166571d74580a706c2ce73 (patch)
treee8f5269c7a88282ade45d6bd9c5770b8c008fc03 /crates/shirabe-external-packages
parent929b2c938ba8c2b83f360b0ba3a04f64075282f8 (diff)
downloadphp-shirabe-dacc1cb0d7d1397701166571d74580a706c2ce73.tar.gz
php-shirabe-dacc1cb0d7d1397701166571d74580a706c2ce73.tar.zst
php-shirabe-dacc1cb0d7d1397701166571d74580a706c2ce73.zip
fix(locker): return stability-flags as int, not string
Locker::get_stability_flags returned IndexMap<String, String>, converting each value via PhpMixed::as_string(), which only matches the String variant. composer.lock's "stability-flags" values are always JSON integers (BasePackage::STABILITIES), so every flag silently decoded to "" and installer.rs's downstream .parse::<i64>() defaulted it to 0 (stable). This made any locked package pinned via a non-stable stability-flags entry look "unacceptable" during `composer install`, silently dropping it from the solver's pool instead of fixing/requiring it — turning a real dependency conflict into a spurious "lock file needs changes" result. Return i64 directly, matching RootPackageInterface::get_stability_flags and set_lock_data's existing convention for this same PHP array shape.
Diffstat (limited to 'crates/shirabe-external-packages')
0 files changed, 0 insertions, 0 deletions