You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rather than in bin/compile's attempt-native-installs-of-polyfill-provided-packages loop, we can figure out if a requested package doesn't actually trigger an install event inside the plugin.
This can happen when a polyfill declares that it provides a particular package, but that package is already there (e.g. because the extension is bundled with PHP and always enabled).
We previously had to handle this on the caller side in bin/compile by tee-ing the installer output to a special file we'd inspect afterwards, since a successful install of a ".native" variant of a package and a "nothing to install or update" outcome both resulted in a 0 exit status, so we could only tell the two apart by checking the output.
GUS-W-18557233
# (the .native "replace"d variant in each extension matches the regular version, so the constraint for that regular version is enough)
537
531
# NO_COLOR=1 suppresses the download progress meter whose ANSI cursor codes trip up output in Heroku Dashboard
538
-
if NO_COLOR=1 composer require -d "$build_dir/.heroku/php""${ext_package}.native:*">>$build_dir/.heroku/php/install.log 2>&1;then
539
-
# package added successfully
540
-
[[ -s"$current_install_log" ]] || { echo"- ${ext_name} (already enabled)"| indent; } # if nothing was actually installed above, that means the dependency was already satisfied (i.e. extension is statically built into PHP); we need to echo something to that effect
done {fd_num}<"$providedextensionslog_file_path"# use bash 4.1+ automatic file descriptor allocation (better than hardcoding e.g. "3<"), otherwise this loop's stdin (the lines of the file) will be consumed by programs called inside the loop
0 commit comments