fix: Repair the phar build on PHP 8.4.

[fago]

Follow-up to #45 (merged). Refs #43.

Problem

composer build — the command needed to produce a new phar for a 0.7.3 release — is broken:

> drunomics\Phapp\ScriptHandler::installPharTools
Downloading box.phar...
$ composer build
[InvalidArgumentException]
Command "compile" is not defined.
Script php -d phar.readonly=0 vendor/bin/box compile handling the build event returned with error code 1

Not a regression from #45. It is a latent bug since 69ac445 (Dec 2024), which bumped the pinned box from box2/2.7.5/box-2.7.5.phar to box/4.6.1/box.phar. Fresh clones happened to work, which is why it went unnoticed; any checkout that predates that bump is broken.

Root cause

Two independent defects in ScriptHandler::installPharTools():

a) The tool symlink was never repointed.

if (!$fs->exists("$bin_dir/$tool")) {
$fs->symlink("$bin_dir/$filename", "$bin_dir/$tool");
}

On a pre-bump checkout vendor/bin/box already existed, pointing at the leftover box-2.7.5.phar. The new box.pharwas downloaded — different basename, so the download guard let it through — but nothing ever linked to it. So composer build kept invoking box 2.7.5, whose command is build, not compile. Hence the error.

b) The download was keyed on the file name only.

if (!$fs->exists("$bin_dir/$filename")) { … }

A new box published under the same box.phar name would never be fetched, so the next version bump would have silently kept the old binary.

Fix

The installer now reconciles vendor/bin with the currently pinned URL:

• the installed URL is recorded in vendor/bin/.<tool>.url;
• the phar is re-downloaded whenever that URL changes, and the phar of the previously pinned version is removed;
• the symlink is updated unconditionally, and is now relative (box -> box.phar) so it keeps working when the project directory is mounted at another path, e.g. inside a container.

Two smaller bugs surfaced along the way:

• $fs->dumpFile($path, $content, 0755) — Filesystem::dumpFile() takes no mode argument, so the third one was silently ignored and the downloaded phar was left non-executable (-rw-rw-r--). Now set explicitly via chmod().
• README: composer install --dev → composer install (--dev is a no-op that Composer 2 warns about and Composer 3 will reject).

Box pinned 4.6.1 → 4.7.0

Box 4.6.1 (Dec 2023) does not run on PHP 8.4 at all, so even with the symlink fixed composer build could not produce a phar there:

box	compile on PHP 8.4	deprecations emitted
4.6.1 (was pinned)	fails, exit 255	260
4.6.10	succeeds	0
4.7.0 (now pinned)	succeeds	0

4.7.0 still builds on PHP 8.3 too, so this does not force maintainers onto 8.4.

Verification

Verified:

• Reproduced the reported failure exactly by restoring the pre-bump vendor/bin state (a box -> box-2.7.5.phar symlink) and running composer install && composer build → [InvalidArgumentException] Command "compile" is not defined.
• That same broken checkout now self-heals: composer install repoints box -> box.phar (4.7.0), and composer build produces phapp.phar.
• Fresh clone path: rm -rf vendor && composer install && composer build succeeds; vendor/bin/box.phar is now correctly -rwxr-xr-x.
• Version-bump path: with .box.url recording 4.6.1 and composer.json pinning 4.7.0, composer install re-downloads and the symlink follows.
• Compiled on PHP 8.4 with box 4.7.0 — 0 deprecations, exit 0 — and the resulting phar runs clean on PHP 8.4 (list, status).
• composer validate → valid (lock content-hash refreshed via composer update --lock; no package versions changed); php -l clean.

Not verified / caveats:

• The PHP 8.4 compile was run with git-version removed from the box config, because the bare php:8.4-cli image has no git binary and my sandbox could not install one. That setting only substitutes the version placeholder and is orthogonal to the PHP version; the full config including git-version was verified on PHP 8.3. The deprecation counts above come from identical configs, so the 4.6.1-vs-4.7.0 comparison is unaffected.
• No test suite exists in this repo, so there is no automated coverage for the installer. Verification was the manual scenarios listed above.
• phpstan analyse src --level=0 still reports the same 2 pre-existing errors in src/ScriptHandler.php (Composer\Script\Event / Composer\Util\StreamContextFactory unknown — composer/composer is not a dependency). Count unchanged by this PR.
• Upgrading checkouts keep a stale vendor/bin/box-2.7.5.phar, since there is no record of it to clean up. It is no longer referenced and is harmless; rm -rf vendor clears it.

Why this matters for #43

#43 is only actually fixed for consumers once a 0.7.3 phar is released, and that phar cannot be built on PHP 8.4 without this PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_018ouHkvipwQik1mwsrrBmUd

[fago]

Follow-up to #45 (merged). Refs #43.

Problem

composer build — the command needed to produce a new phar for a 0.7.3 release — is broken:

> drunomics\Phapp\ScriptHandler::installPharTools
Downloading box.phar...
$ composer build
[InvalidArgumentException]
Command "compile" is not defined.
Script php -d phar.readonly=0 vendor/bin/box compile handling the build event returned with error code 1

Not a regression from #45. It is a latent bug since 69ac445 (Dec 2024), which bumped the pinned box from box2/2.7.5/box-2.7.5.phar to box/4.6.1/box.phar. Fresh clones happened to work, which is why it went unnoticed; any checkout that predates that bump is broken.

Root cause

Two independent defects in ScriptHandler::installPharTools():

a) The tool symlink was never repointed.

if (!$fs->exists("$bin_dir/$tool")) {
$fs->symlink("$bin_dir/$filename", "$bin_dir/$tool");
}

On a pre-bump checkout vendor/bin/box already existed, pointing at the leftover box-2.7.5.phar. The new box.pharwas downloaded — different basename, so the download guard let it through — but nothing ever linked to it. So composer build kept invoking box 2.7.5, whose command is build, not compile. Hence the error.

b) The download was keyed on the file name only.

if (!$fs->exists("$bin_dir/$filename")) { … }

A new box published under the same box.phar name would never be fetched, so the next version bump would have silently kept the old binary.

Fix

The installer now reconciles vendor/bin with the currently pinned URL:

• the installed URL is recorded in vendor/bin/.<tool>.url;
• the phar is re-downloaded whenever that URL changes, and the phar of the previously pinned version is removed;
• the symlink is updated unconditionally, and is now relative (box -> box.phar) so it keeps working when the project directory is mounted at another path, e.g. inside a container.

Two smaller bugs surfaced along the way:

• $fs->dumpFile($path, $content, 0755) — Filesystem::dumpFile() takes no mode argument, so the third one was silently ignored and the downloaded phar was left non-executable (-rw-rw-r--). Now set explicitly via chmod().
• README: composer install --dev → composer install (--dev is a no-op that Composer 2 warns about and Composer 3 will reject).

Box pinned 4.6.1 → 4.7.0

Box 4.6.1 (Dec 2023) does not run on PHP 8.4 at all, so even with the symlink fixed composer build could not produce a phar there:

box	compile on PHP 8.4	deprecations emitted
4.6.1 (was pinned)	fails, exit 255	260
4.6.10	succeeds	0
4.7.0 (now pinned)	succeeds	0

4.7.0 still builds on PHP 8.3 too, so this does not force maintainers onto 8.4.

Verification

Verified:

• Reproduced the reported failure exactly by restoring the pre-bump vendor/bin state (a box -> box-2.7.5.phar symlink) and running composer install && composer build → [InvalidArgumentException] Command "compile" is not defined.
• That same broken checkout now self-heals: composer install repoints box -> box.phar (4.7.0), and composer build produces phapp.phar.
• Fresh clone path: rm -rf vendor && composer install && composer build succeeds; vendor/bin/box.phar is now correctly -rwxr-xr-x.
• Version-bump path: with .box.url recording 4.6.1 and composer.json pinning 4.7.0, composer install re-downloads and the symlink follows.
• Compiled on PHP 8.4 with box 4.7.0 — 0 deprecations, exit 0 — and the resulting phar runs clean on PHP 8.4 (list, status).
• composer validate → valid (lock content-hash refreshed via composer update --lock; no package versions changed); php -l clean.

Not verified / caveats:

• The PHP 8.4 compile was run with git-version removed from the box config, because the bare php:8.4-cli image has no git binary and my sandbox could not install one. That setting only substitutes the version placeholder and is orthogonal to the PHP version; the full config including git-version was verified on PHP 8.3. The deprecation counts above come from identical configs, so the 4.6.1-vs-4.7.0 comparison is unaffected.
• No test suite exists in this repo, so there is no automated coverage for the installer. Verification was the manual scenarios listed above.
• phpstan analyse src --level=0 still reports the same 2 pre-existing errors in src/ScriptHandler.php (Composer\Script\Event / Composer\Util\StreamContextFactory unknown — composer/composer is not a dependency). Count unchanged by this PR.
• Upgrading checkouts keep a stale vendor/bin/box-2.7.5.phar, since there is no record of it to clean up. It is no longer referenced and is harmless; rm -rf vendor clears it.

Why this matters for #43

#43 is only actually fixed for consumers once a 0.7.3 phar is released, and that phar cannot be built on PHP 8.4 without this PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_018ouHkvipwQik1mwsrrBmUd

[fago]

Follow-up to #45 (merged). Refs #43.

Problem

composer build — the command needed to produce a new phar for a 0.7.3 release — is broken:

> drunomics\Phapp\ScriptHandler::installPharTools
Downloading box.phar...
$ composer build
[InvalidArgumentException]
Command "compile" is not defined.
Script php -d phar.readonly=0 vendor/bin/box compile handling the build event returned with error code 1

Not a regression from #45. It is a latent bug since 69ac445 (Dec 2024), which bumped the pinned box from box2/2.7.5/box-2.7.5.phar to box/4.6.1/box.phar. Fresh clones happened to work, which is why it went unnoticed; any checkout that predates that bump is broken.

Root cause

Two independent defects in ScriptHandler::installPharTools():

a) The tool symlink was never repointed.

if (!$fs->exists("$bin_dir/$tool")) {
$fs->symlink("$bin_dir/$filename", "$bin_dir/$tool");
}

On a pre-bump checkout vendor/bin/box already existed, pointing at the leftover box-2.7.5.phar. The new box.pharwas downloaded — different basename, so the download guard let it through — but nothing ever linked to it. So composer build kept invoking box 2.7.5, whose command is build, not compile. Hence the error.

b) The download was keyed on the file name only.

if (!$fs->exists("$bin_dir/$filename")) { … }

A new box published under the same box.phar name would never be fetched, so the next version bump would have silently kept the old binary.

Fix

The installer now reconciles vendor/bin with the currently pinned URL:

• the installed URL is recorded in vendor/bin/.<tool>.url;
• the phar is re-downloaded whenever that URL changes, and the phar of the previously pinned version is removed;
• the symlink is updated unconditionally, and is now relative (box -> box.phar) so it keeps working when the project directory is mounted at another path, e.g. inside a container.

Two smaller bugs surfaced along the way:

• $fs->dumpFile($path, $content, 0755) — Filesystem::dumpFile() takes no mode argument, so the third one was silently ignored and the downloaded phar was left non-executable (-rw-rw-r--). Now set explicitly via chmod().
• README: composer install --dev → composer install (--dev is a no-op that Composer 2 warns about and Composer 3 will reject).

Box pinned 4.6.1 → 4.7.0

Box 4.6.1 (Dec 2023) does not run on PHP 8.4 at all, so even with the symlink fixed composer build could not produce a phar there:

box	compile on PHP 8.4	deprecations emitted
4.6.1 (was pinned)	fails, exit 255	260
4.6.10	succeeds	0
4.7.0 (now pinned)	succeeds	0

4.7.0 still builds on PHP 8.3 too, so this does not force maintainers onto 8.4.

Verification

Verified:

• Reproduced the reported failure exactly by restoring the pre-bump vendor/bin state (a box -> box-2.7.5.phar symlink) and running composer install && composer build → [InvalidArgumentException] Command "compile" is not defined.
• That same broken checkout now self-heals: composer install repoints box -> box.phar (4.7.0), and composer build produces phapp.phar.
• Fresh clone path: rm -rf vendor && composer install && composer build succeeds; vendor/bin/box.phar is now correctly -rwxr-xr-x.
• Version-bump path: with .box.url recording 4.6.1 and composer.json pinning 4.7.0, composer install re-downloads and the symlink follows.
• Compiled on PHP 8.4 with box 4.7.0 — 0 deprecations, exit 0 — and the resulting phar runs clean on PHP 8.4 (list, status).
• composer validate → valid (lock content-hash refreshed via composer update --lock; no package versions changed); php -l clean.

Not verified / caveats:

• The PHP 8.4 compile was run with git-version removed from the box config, because the bare php:8.4-cli image has no git binary and my sandbox could not install one. That setting only substitutes the version placeholder and is orthogonal to the PHP version; the full config including git-version was verified on PHP 8.3. The deprecation counts above come from identical configs, so the 4.6.1-vs-4.7.0 comparison is unaffected.
• No test suite exists in this repo, so there is no automated coverage for the installer. Verification was the manual scenarios listed above.
• phpstan analyse src --level=0 still reports the same 2 pre-existing errors in src/ScriptHandler.php (Composer\Script\Event / Composer\Util\StreamContextFactory unknown — composer/composer is not a dependency). Count unchanged by this PR.
• Upgrading checkouts keep a stale vendor/bin/box-2.7.5.phar, since there is no record of it to clean up. It is no longer referenced and is harmless; rm -rf vendor clears it.

Why this matters for #43

#43 is only actually fixed for consumers once a 0.7.3 phar is released, and that phar cannot be built on PHP 8.4 without this PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_018ouHkvipwQik1mwsrrBmUd

[fago]

Follow-up to #45 (merged). Refs #43.

Problem

composer build — the command needed to produce a new phar for a 0.7.3 release — is broken:

> drunomics\Phapp\ScriptHandler::installPharTools
Downloading box.phar...
$ composer build
[InvalidArgumentException]
Command "compile" is not defined.
Script php -d phar.readonly=0 vendor/bin/box compile handling the build event returned with error code 1

Not a regression from #45. It is a latent bug since 69ac445 (Dec 2024), which bumped the pinned box from box2/2.7.5/box-2.7.5.phar to box/4.6.1/box.phar. Fresh clones happened to work, which is why it went unnoticed; any checkout that predates that bump is broken.

Root cause

Two independent defects in ScriptHandler::installPharTools():

a) The tool symlink was never repointed.

if (!$fs->exists("$bin_dir/$tool")) {
$fs->symlink("$bin_dir/$filename", "$bin_dir/$tool");
}

On a pre-bump checkout vendor/bin/box already existed, pointing at the leftover box-2.7.5.phar. The new box.pharwas downloaded — different basename, so the download guard let it through — but nothing ever linked to it. So composer build kept invoking box 2.7.5, whose command is build, not compile. Hence the error.

b) The download was keyed on the file name only.

if (!$fs->exists("$bin_dir/$filename")) { … }

A new box published under the same box.phar name would never be fetched, so the next version bump would have silently kept the old binary.

Fix

The installer now reconciles vendor/bin with the currently pinned URL:

• the installed URL is recorded in vendor/bin/.<tool>.url;
• the phar is re-downloaded whenever that URL changes, and the phar of the previously pinned version is removed;
• the symlink is updated unconditionally, and is now relative (box -> box.phar) so it keeps working when the project directory is mounted at another path, e.g. inside a container.

Two smaller bugs surfaced along the way:

• $fs->dumpFile($path, $content, 0755) — Filesystem::dumpFile() takes no mode argument, so the third one was silently ignored and the downloaded phar was left non-executable (-rw-rw-r--). Now set explicitly via chmod().
• README: composer install --dev → composer install (--dev is a no-op that Composer 2 warns about and Composer 3 will reject).

Box pinned 4.6.1 → 4.7.0

Box 4.6.1 (Dec 2023) does not run on PHP 8.4 at all, so even with the symlink fixed composer build could not produce a phar there:

box	compile on PHP 8.4	deprecations emitted
4.6.1 (was pinned)	fails, exit 255	260
4.6.10	succeeds	0
4.7.0 (now pinned)	succeeds	0

4.7.0 still builds on PHP 8.3 too, so this does not force maintainers onto 8.4.

Verification

Verified:

• Reproduced the reported failure exactly by restoring the pre-bump vendor/bin state (a box -> box-2.7.5.phar symlink) and running composer install && composer build → [InvalidArgumentException] Command "compile" is not defined.
• That same broken checkout now self-heals: composer install repoints box -> box.phar (4.7.0), and composer build produces phapp.phar.
• Fresh clone path: rm -rf vendor && composer install && composer build succeeds; vendor/bin/box.phar is now correctly -rwxr-xr-x.
• Version-bump path: with .box.url recording 4.6.1 and composer.json pinning 4.7.0, composer install re-downloads and the symlink follows.
• Compiled on PHP 8.4 with box 4.7.0 — 0 deprecations, exit 0 — and the resulting phar runs clean on PHP 8.4 (list, status).
• composer validate → valid (lock content-hash refreshed via composer update --lock; no package versions changed); php -l clean.

Not verified / caveats:

• The PHP 8.4 compile was run with git-version removed from the box config, because the bare php:8.4-cli image has no git binary and my sandbox could not install one. That setting only substitutes the version placeholder and is orthogonal to the PHP version; the full config including git-version was verified on PHP 8.3. The deprecation counts above come from identical configs, so the 4.6.1-vs-4.7.0 comparison is unaffected.
• No test suite exists in this repo, so there is no automated coverage for the installer. Verification was the manual scenarios listed above.
• phpstan analyse src --level=0 still reports the same 2 pre-existing errors in src/ScriptHandler.php (Composer\Script\Event / Composer\Util\StreamContextFactory unknown — composer/composer is not a dependency). Count unchanged by this PR.
• Upgrading checkouts keep a stale vendor/bin/box-2.7.5.phar, since there is no record of it to clean up. It is no longer referenced and is harmless; rm -rf vendor clears it.

Why this matters for #43

#43 is only actually fixed for consumers once a 0.7.3 phar is released, and that phar cannot be built on PHP 8.4 without this PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_018ouHkvipwQik1mwsrrBmUd

[fago]

Follow-up to #45 (merged). Refs #43.

Problem

composer build — the command needed to produce a new phar for a 0.7.3 release — is broken:

> drunomics\Phapp\ScriptHandler::installPharTools
Downloading box.phar...
$ composer build
[InvalidArgumentException]
Command "compile" is not defined.
Script php -d phar.readonly=0 vendor/bin/box compile handling the build event returned with error code 1

Not a regression from #45. It is a latent bug since 69ac445 (Dec 2024), which bumped the pinned box from box2/2.7.5/box-2.7.5.phar to box/4.6.1/box.phar. Fresh clones happened to work, which is why it went unnoticed; any checkout that predates that bump is broken.

Root cause

Two independent defects in ScriptHandler::installPharTools():

a) The tool symlink was never repointed.

if (!$fs->exists("$bin_dir/$tool")) {
$fs->symlink("$bin_dir/$filename", "$bin_dir/$tool");
}

On a pre-bump checkout vendor/bin/box already existed, pointing at the leftover box-2.7.5.phar. The new box.pharwas downloaded — different basename, so the download guard let it through — but nothing ever linked to it. So composer build kept invoking box 2.7.5, whose command is build, not compile. Hence the error.

b) The download was keyed on the file name only.

if (!$fs->exists("$bin_dir/$filename")) { … }

A new box published under the same box.phar name would never be fetched, so the next version bump would have silently kept the old binary.

Fix

The installer now reconciles vendor/bin with the currently pinned URL:

• the installed URL is recorded in vendor/bin/.<tool>.url;
• the phar is re-downloaded whenever that URL changes, and the phar of the previously pinned version is removed;
• the symlink is updated unconditionally, and is now relative (box -> box.phar) so it keeps working when the project directory is mounted at another path, e.g. inside a container.

Two smaller bugs surfaced along the way:

• $fs->dumpFile($path, $content, 0755) — Filesystem::dumpFile() takes no mode argument, so the third one was silently ignored and the downloaded phar was left non-executable (-rw-rw-r--). Now set explicitly via chmod().
• README: composer install --dev → composer install (--dev is a no-op that Composer 2 warns about and Composer 3 will reject).

Box pinned 4.6.1 → 4.7.0

Box 4.6.1 (Dec 2023) does not run on PHP 8.4 at all, so even with the symlink fixed composer build could not produce a phar there:

box	compile on PHP 8.4	deprecations emitted
4.6.1 (was pinned)	fails, exit 255	260
4.6.10	succeeds	0
4.7.0 (now pinned)	succeeds	0

4.7.0 still builds on PHP 8.3 too, so this does not force maintainers onto 8.4.

Verification

Verified:

• Reproduced the reported failure exactly by restoring the pre-bump vendor/bin state (a box -> box-2.7.5.phar symlink) and running composer install && composer build → [InvalidArgumentException] Command "compile" is not defined.
• That same broken checkout now self-heals: composer install repoints box -> box.phar (4.7.0), and composer build produces phapp.phar.
• Fresh clone path: rm -rf vendor && composer install && composer build succeeds; vendor/bin/box.phar is now correctly -rwxr-xr-x.
• Version-bump path: with .box.url recording 4.6.1 and composer.json pinning 4.7.0, composer install re-downloads and the symlink follows.
• Compiled on PHP 8.4 with box 4.7.0 — 0 deprecations, exit 0 — and the resulting phar runs clean on PHP 8.4 (list, status).
• composer validate → valid (lock content-hash refreshed via composer update --lock; no package versions changed); php -l clean.

Not verified / caveats:

• The PHP 8.4 compile was run with git-version removed from the box config, because the bare php:8.4-cli image has no git binary and my sandbox could not install one. That setting only substitutes the version placeholder and is orthogonal to the PHP version; the full config including git-version was verified on PHP 8.3. The deprecation counts above come from identical configs, so the 4.6.1-vs-4.7.0 comparison is unaffected.
• No test suite exists in this repo, so there is no automated coverage for the installer. Verification was the manual scenarios listed above.
• phpstan analyse src --level=0 still reports the same 2 pre-existing errors in src/ScriptHandler.php (Composer\Script\Event / Composer\Util\StreamContextFactory unknown — composer/composer is not a dependency). Count unchanged by this PR.
• Upgrading checkouts keep a stale vendor/bin/box-2.7.5.phar, since there is no record of it to clean up. It is no longer referenced and is harmless; rm -rf vendor clears it.

Why this matters for #43

#43 is only actually fixed for consumers once a 0.7.3 phar is released, and that phar cannot be built on PHP 8.4 without this PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_018ouHkvipwQik1mwsrrBmUd

[fago]

Follow-up to #45 (merged). Refs #43.

Problem

composer build — the command needed to produce a new phar for a 0.7.3 release — is broken:

> drunomics\Phapp\ScriptHandler::installPharTools
Downloading box.phar...
$ composer build
[InvalidArgumentException]
Command "compile" is not defined.
Script php -d phar.readonly=0 vendor/bin/box compile handling the build event returned with error code 1

Not a regression from #45. It is a latent bug since 69ac445 (Dec 2024), which bumped the pinned box from box2/2.7.5/box-2.7.5.phar to box/4.6.1/box.phar. Fresh clones happened to work, which is why it went unnoticed; any checkout that predates that bump is broken.

Root cause

Two independent defects in ScriptHandler::installPharTools():

a) The tool symlink was never repointed.

if (!$fs->exists("$bin_dir/$tool")) {
$fs->symlink("$bin_dir/$filename", "$bin_dir/$tool");
}

On a pre-bump checkout vendor/bin/box already existed, pointing at the leftover box-2.7.5.phar. The new box.pharwas downloaded — different basename, so the download guard let it through — but nothing ever linked to it. So composer build kept invoking box 2.7.5, whose command is build, not compile. Hence the error.

b) The download was keyed on the file name only.

if (!$fs->exists("$bin_dir/$filename")) { … }

A new box published under the same box.phar name would never be fetched, so the next version bump would have silently kept the old binary.

Fix

The installer now reconciles vendor/bin with the currently pinned URL:

• the installed URL is recorded in vendor/bin/.<tool>.url;
• the phar is re-downloaded whenever that URL changes, and the phar of the previously pinned version is removed;
• the symlink is updated unconditionally, and is now relative (box -> box.phar) so it keeps working when the project directory is mounted at another path, e.g. inside a container.

Two smaller bugs surfaced along the way:

• $fs->dumpFile($path, $content, 0755) — Filesystem::dumpFile() takes no mode argument, so the third one was silently ignored and the downloaded phar was left non-executable (-rw-rw-r--). Now set explicitly via chmod().
• README: composer install --dev → composer install (--dev is a no-op that Composer 2 warns about and Composer 3 will reject).

Box pinned 4.6.1 → 4.7.0

Box 4.6.1 (Dec 2023) does not run on PHP 8.4 at all, so even with the symlink fixed composer build could not produce a phar there:

box	compile on PHP 8.4	deprecations emitted
4.6.1 (was pinned)	fails, exit 255	260
4.6.10	succeeds	0
4.7.0 (now pinned)	succeeds	0

4.7.0 still builds on PHP 8.3 too, so this does not force maintainers onto 8.4.

Verification

Verified:

• Reproduced the reported failure exactly by restoring the pre-bump vendor/bin state (a box -> box-2.7.5.phar symlink) and running composer install && composer build → [InvalidArgumentException] Command "compile" is not defined.
• That same broken checkout now self-heals: composer install repoints box -> box.phar (4.7.0), and composer build produces phapp.phar.
• Fresh clone path: rm -rf vendor && composer install && composer build succeeds; vendor/bin/box.phar is now correctly -rwxr-xr-x.
• Version-bump path: with .box.url recording 4.6.1 and composer.json pinning 4.7.0, composer install re-downloads and the symlink follows.
• Compiled on PHP 8.4 with box 4.7.0 — 0 deprecations, exit 0 — and the resulting phar runs clean on PHP 8.4 (list, status).
• composer validate → valid (lock content-hash refreshed via composer update --lock; no package versions changed); php -l clean.

Not verified / caveats:

• The PHP 8.4 compile was run with git-version removed from the box config, because the bare php:8.4-cli image has no git binary and my sandbox could not install one. That setting only substitutes the version placeholder and is orthogonal to the PHP version; the full config including git-version was verified on PHP 8.3. The deprecation counts above come from identical configs, so the 4.6.1-vs-4.7.0 comparison is unaffected.
• No test suite exists in this repo, so there is no automated coverage for the installer. Verification was the manual scenarios listed above.
• phpstan analyse src --level=0 still reports the same 2 pre-existing errors in src/ScriptHandler.php (Composer\Script\Event / Composer\Util\StreamContextFactory unknown — composer/composer is not a dependency). Count unchanged by this PR.
• Upgrading checkouts keep a stale vendor/bin/box-2.7.5.phar, since there is no record of it to clean up. It is no longer referenced and is harmless; rm -rf vendor clears it.

Why this matters for #43

#43 is only actually fixed for consumers once a 0.7.3 phar is released, and that phar cannot be built on PHP 8.4 without this PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_018ouHkvipwQik1mwsrrBmUd

[fago]

Follow-up to #45 (merged). Refs #43.

Problem

composer build — the command needed to produce a new phar for a 0.7.3 release — is broken:

> drunomics\Phapp\ScriptHandler::installPharTools
Downloading box.phar...
$ composer build
[InvalidArgumentException]
Command "compile" is not defined.
Script php -d phar.readonly=0 vendor/bin/box compile handling the build event returned with error code 1

Not a regression from #45. It is a latent bug since 69ac445 (Dec 2024), which bumped the pinned box from box2/2.7.5/box-2.7.5.phar to box/4.6.1/box.phar. Fresh clones happened to work, which is why it went unnoticed; any checkout that predates that bump is broken.

Root cause

Two independent defects in ScriptHandler::installPharTools():

a) The tool symlink was never repointed.

if (!$fs->exists("$bin_dir/$tool")) {
$fs->symlink("$bin_dir/$filename", "$bin_dir/$tool");
}

On a pre-bump checkout vendor/bin/box already existed, pointing at the leftover box-2.7.5.phar. The new box.pharwas downloaded — different basename, so the download guard let it through — but nothing ever linked to it. So composer build kept invoking box 2.7.5, whose command is build, not compile. Hence the error.

b) The download was keyed on the file name only.

if (!$fs->exists("$bin_dir/$filename")) { … }

A new box published under the same box.phar name would never be fetched, so the next version bump would have silently kept the old binary.

Fix

The installer now reconciles vendor/bin with the currently pinned URL:

• the installed URL is recorded in vendor/bin/.<tool>.url;
• the phar is re-downloaded whenever that URL changes, and the phar of the previously pinned version is removed;
• the symlink is updated unconditionally, and is now relative (box -> box.phar) so it keeps working when the project directory is mounted at another path, e.g. inside a container.

Two smaller bugs surfaced along the way:

• $fs->dumpFile($path, $content, 0755) — Filesystem::dumpFile() takes no mode argument, so the third one was silently ignored and the downloaded phar was left non-executable (-rw-rw-r--). Now set explicitly via chmod().
• README: composer install --dev → composer install (--dev is a no-op that Composer 2 warns about and Composer 3 will reject).

Box pinned 4.6.1 → 4.7.0

Box 4.6.1 (Dec 2023) does not run on PHP 8.4 at all, so even with the symlink fixed composer build could not produce a phar there:

box	compile on PHP 8.4	deprecations emitted
4.6.1 (was pinned)	fails, exit 255	260
4.6.10	succeeds	0
4.7.0 (now pinned)	succeeds	0

4.7.0 still builds on PHP 8.3 too, so this does not force maintainers onto 8.4.

Verification

Verified:

• Reproduced the reported failure exactly by restoring the pre-bump vendor/bin state (a box -> box-2.7.5.phar symlink) and running composer install && composer build → [InvalidArgumentException] Command "compile" is not defined.
• That same broken checkout now self-heals: composer install repoints box -> box.phar (4.7.0), and composer build produces phapp.phar.
• Fresh clone path: rm -rf vendor && composer install && composer build succeeds; vendor/bin/box.phar is now correctly -rwxr-xr-x.
• Version-bump path: with .box.url recording 4.6.1 and composer.json pinning 4.7.0, composer install re-downloads and the symlink follows.
• Compiled on PHP 8.4 with box 4.7.0 — 0 deprecations, exit 0 — and the resulting phar runs clean on PHP 8.4 (list, status).
• composer validate → valid (lock content-hash refreshed via composer update --lock; no package versions changed); php -l clean.

Not verified / caveats:

• The PHP 8.4 compile was run with git-version removed from the box config, because the bare php:8.4-cli image has no git binary and my sandbox could not install one. That setting only substitutes the version placeholder and is orthogonal to the PHP version; the full config including git-version was verified on PHP 8.3. The deprecation counts above come from identical configs, so the 4.6.1-vs-4.7.0 comparison is unaffected.
• No test suite exists in this repo, so there is no automated coverage for the installer. Verification was the manual scenarios listed above.
• phpstan analyse src --level=0 still reports the same 2 pre-existing errors in src/ScriptHandler.php (Composer\Script\Event / Composer\Util\StreamContextFactory unknown — composer/composer is not a dependency). Count unchanged by this PR.
• Upgrading checkouts keep a stale vendor/bin/box-2.7.5.phar, since there is no record of it to clean up. It is no longer referenced and is harmless; rm -rf vendor clears it.

Why this matters for #43

#43 is only actually fixed for consumers once a 0.7.3 phar is released, and that phar cannot be built on PHP 8.4 without this PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_018ouHkvipwQik1mwsrrBmUd

[fago]

Follow-up to #45 (merged). Refs #43.

Problem

composer build — the command needed to produce a new phar for a 0.7.3 release — is broken:

> drunomics\Phapp\ScriptHandler::installPharTools
Downloading box.phar...
$ composer build
[InvalidArgumentException]
Command "compile" is not defined.
Script php -d phar.readonly=0 vendor/bin/box compile handling the build event returned with error code 1

Not a regression from #45. It is a latent bug since 69ac445 (Dec 2024), which bumped the pinned box from box2/2.7.5/box-2.7.5.phar to box/4.6.1/box.phar. Fresh clones happened to work, which is why it went unnoticed; any checkout that predates that bump is broken.

Root cause

Two independent defects in ScriptHandler::installPharTools():

a) The tool symlink was never repointed.

if (!$fs->exists("$bin_dir/$tool")) {
$fs->symlink("$bin_dir/$filename", "$bin_dir/$tool");
}

On a pre-bump checkout vendor/bin/box already existed, pointing at the leftover box-2.7.5.phar. The new box.pharwas downloaded — different basename, so the download guard let it through — but nothing ever linked to it. So composer build kept invoking box 2.7.5, whose command is build, not compile. Hence the error.

b) The download was keyed on the file name only.

if (!$fs->exists("$bin_dir/$filename")) { … }

A new box published under the same box.phar name would never be fetched, so the next version bump would have silently kept the old binary.

Fix

The installer now reconciles vendor/bin with the currently pinned URL:

• the installed URL is recorded in vendor/bin/.<tool>.url;
• the phar is re-downloaded whenever that URL changes, and the phar of the previously pinned version is removed;
• the symlink is updated unconditionally, and is now relative (box -> box.phar) so it keeps working when the project directory is mounted at another path, e.g. inside a container.

Two smaller bugs surfaced along the way:

• $fs->dumpFile($path, $content, 0755) — Filesystem::dumpFile() takes no mode argument, so the third one was silently ignored and the downloaded phar was left non-executable (-rw-rw-r--). Now set explicitly via chmod().
• README: composer install --dev → composer install (--dev is a no-op that Composer 2 warns about and Composer 3 will reject).

Box pinned 4.6.1 → 4.7.0

Box 4.6.1 (Dec 2023) does not run on PHP 8.4 at all, so even with the symlink fixed composer build could not produce a phar there:

box	compile on PHP 8.4	deprecations emitted
4.6.1 (was pinned)	fails, exit 255	260
4.6.10	succeeds	0
4.7.0 (now pinned)	succeeds	0

4.7.0 still builds on PHP 8.3 too, so this does not force maintainers onto 8.4.

Verification

Verified:

• Reproduced the reported failure exactly by restoring the pre-bump vendor/bin state (a box -> box-2.7.5.phar symlink) and running composer install && composer build → [InvalidArgumentException] Command "compile" is not defined.
• That same broken checkout now self-heals: composer install repoints box -> box.phar (4.7.0), and composer build produces phapp.phar.
• Fresh clone path: rm -rf vendor && composer install && composer build succeeds; vendor/bin/box.phar is now correctly -rwxr-xr-x.
• Version-bump path: with .box.url recording 4.6.1 and composer.json pinning 4.7.0, composer install re-downloads and the symlink follows.
• Compiled on PHP 8.4 with box 4.7.0 — 0 deprecations, exit 0 — and the resulting phar runs clean on PHP 8.4 (list, status).
• composer validate → valid (lock content-hash refreshed via composer update --lock; no package versions changed); php -l clean.

Not verified / caveats:

• The PHP 8.4 compile was run with git-version removed from the box config, because the bare php:8.4-cli image has no git binary and my sandbox could not install one. That setting only substitutes the version placeholder and is orthogonal to the PHP version; the full config including git-version was verified on PHP 8.3. The deprecation counts above come from identical configs, so the 4.6.1-vs-4.7.0 comparison is unaffected.
• No test suite exists in this repo, so there is no automated coverage for the installer. Verification was the manual scenarios listed above.
• phpstan analyse src --level=0 still reports the same 2 pre-existing errors in src/ScriptHandler.php (Composer\Script\Event / Composer\Util\StreamContextFactory unknown — composer/composer is not a dependency). Count unchanged by this PR.
• Upgrading checkouts keep a stale vendor/bin/box-2.7.5.phar, since there is no record of it to clean up. It is no longer referenced and is harmless; rm -rf vendor clears it.

Why this matters for #43

#43 is only actually fixed for consumers once a 0.7.3 phar is released, and that phar cannot be built on PHP 8.4 without this PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_018ouHkvipwQik1mwsrrBmUd