Fix composer version fallback and self-update binary sync by jakwinkler · Pull Request #80 · qoliber/magebox

jakwinkler · 2026-04-09T10:16:07Z

Allow unknown Magento/MageOS versions in composer.json generation instead of erroring, using sensible defaults for plugin constraints. This fixes magebox new when the daily-updated version registry adds versions not in the hardcoded map.
Self-update now syncs the updated binary to all known locations (~/.magebox/bin/magebox, ~/.magebox/bin/mbox, /usr/local/bin/magebox, /usr/local/bin/mbox) to prevent version mismatches.
Updated troubleshooting docs for version mismatch and unsupported version errors.
I've also added option to install in current directory
mbox new ./ --quick

Copilot

Pull request overview

This PR improves robustness of magebox new against newly published Magento/MageOS versions and reduces mbox/magebox version mismatches after self-update.

Changes:

Allow unknown Magento/MageOS versions in composer.json generation by falling back to default plugin constraints instead of erroring.
Extend self-update to sync the updated binary into multiple known install locations.
Update docs/changelog and bump version to 1.14.1.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
`internal/templates/composer.go`	Adds fallback behavior for unknown Magento/MageOS versions during composer.json generation.
`internal/updater/updater.go`	Adds post-update syncing of the updated binary to additional known paths.
`vitepress/guide/troubleshooting.md`	Documents version mismatch troubleshooting and unsupported-version guidance.
`vitepress/guide/installation.md`	Notes that `self-update` syncs binaries to multiple locations.
`CHANGELOG.md`	Adds `1.14.1` release notes for the fixes.
`VERSION`	Bumps version from `1.14.0` to `1.14.1`.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-04-09T10:22:13Z

+		// Skip symlinks — they'll resolve to the updated target
+		fi, err := os.Lstat(loc)
+		if err != nil {
+			continue
+		}
+		if fi.Mode()&os.ModeSymlink != 0 {
+			continue
+		}


syncBinaryLocations skips a location entirely when os.Lstat(loc) fails (e.g., the file doesn't exist yet). That means some “known locations” (like ~/.magebox/bin/mbox on a fresh install, or /usr/local/bin/mbox if it hasn’t been created) will never get created/synced. Consider handling os.IsNotExist(err) by creating the parent dir (when applicable) and writing/copying the binary, or adjust the docs/function comment to clarify that only existing files are synced.

Copilot · 2026-04-09T10:22:14Z

+		// Copy binary to this location
+		data, err := os.ReadFile(sourcePath)
+		if err != nil {
+			continue
+		}
+


The updated binary is read from disk once per target location (os.ReadFile(sourcePath) inside the loop). Since sourcePath is constant, this can be read once before the loop and reused for all writes/copies to avoid repeated I/O (and simplify error handling).

Copilot · 2026-04-09T10:22:14Z

+			// Try with sudo for system paths
+			if strings.HasPrefix(loc, "/usr/") {
+				cmd := exec.Command("sudo", "cp", sourcePath, loc)
+				_ = cmd.Run()


When os.WriteFile fails for system paths, the fallback sudo cp is executed but any failure is ignored (_ = cmd.Run()). If the sudo copy fails (no TTY, user cancels, sudo not installed, etc.), self-update will still report success and the user can remain in a mismatched state. Consider capturing the error and either returning a warning/error from syncBinaryLocations, or at least surfacing a log/message for failed sync targets.

Suggested change

_ = cmd.Run()

if sudoErr := cmd.Run(); sudoErr != nil {

fmt.Fprintf(os.Stderr, "warning: failed to sync binary to %s using sudo cp: %v (initial write error: %v)\n", loc, sudoErr, err)

}

} else {

fmt.Fprintf(os.Stderr, "warning: failed to sync binary to %s: %v\n", loc, err)

Copilot · 2026-04-09T10:22:14Z

 ## Getting Help

+## Version Mismatch Between `mbox` and `magebox`
+
+If `mbox --version` and `magebox --version` show different versions, you have multiple binaries in your PATH:


## Getting Help is now immediately followed by another ## heading, leaving the “Getting Help” section empty. Consider either removing ## Getting Help or making the new entries subheadings (e.g., ### ...) so the document structure is consistent.

Copilot · 2026-04-09T10:22:14Z

+**Solution:** Run `magebox self-update` — since v1.14.1, self-update syncs all known binary locations automatically. Or manually:
+
+```bash
+# Copy the latest binary to all locations
+cp $(which magebox) ~/.magebox/bin/mbox
+sudo cp $(which magebox) /usr/local/bin/magebox
+sudo ln -sf /usr/local/bin/magebox /usr/local/bin/mbox


The troubleshooting section lists ~/.local/bin/mbox as a common location, but the “since v1.14.1, self-update syncs all known binary locations automatically” text can be read as including it. The updater code only syncs ~/.magebox/bin/* and /usr/local/bin/*, so consider clarifying that ~/.local/bin/mbox is not auto-synced (and should be removed from PATH / manually updated), or update the sync list to include it.

Suggested change

**Solution:** Run `magebox self-update` — since v1.14.1, self-update syncs all known binary locations automatically. Or manually:

```bash

# Copy the latest binary to all locations

cp $(which magebox) ~/.magebox/bin/mbox

sudo cp $(which magebox) /usr/local/bin/magebox

sudo ln -sf /usr/local/bin/magebox /usr/local/bin/mbox

**Solution:** Run `magebox self-update` — since v1.14.1, self-update auto-syncs the managed binary locations in `~/.magebox/bin/*` and `/usr/local/bin/*`. It does **not** update older installs such as `~/.local/bin/mbox`, so remove that from your `PATH` or update/remove it manually. Or manually:

```bash

# Copy the latest binary to the managed locations

cp $(which magebox) ~/.magebox/bin/mbox

sudo cp $(which magebox) /usr/local/bin/magebox

sudo ln -sf /usr/local/bin/magebox /usr/local/bin/mbox

# Remove an older ~/.local/bin/mbox if present so it doesn't shadow the updated binary

rm -f ~/.local/bin/mbox

Copilot · 2026-04-09T10:22:15Z

+		}
+
+		if err := os.WriteFile(loc, data, 0755); err != nil {
+			// Try with sudo for system paths
+			if strings.HasPrefix(loc, "/usr/") {


Writing the binary via os.WriteFile(loc, data, 0755) is not atomic (it truncates and writes in-place). If the process is interrupted, it can leave loc as a corrupted/partial binary. Consider using an atomic install pattern (write to a temp file in the same directory, chmod, then os.Rename) similar to the main update path, and only fall back to sudo for the final move/copy when needed.

…ling - Allow unknown Magento/MageOS versions in composer.json generation instead of erroring, using sensible defaults for plugin constraints. This fixes `magebox new` when the daily-updated version registry adds versions not in the hardcoded map. - Self-update now syncs the updated binary to all known locations (~/.magebox/bin/magebox, ~/.magebox/bin/mbox, /usr/local/bin/magebox, /usr/local/bin/mbox) to prevent version mismatches. - Fix `magebox new ./` resolving project name to "." instead of the current directory name. Now normalizes paths via filepath.Clean. - Updated troubleshooting docs for version mismatch and unsupported version errors. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

jakwinkler mentioned this pull request Apr 9, 2026

Installing failure #78

Closed

jakwinkler requested review from Copilot and peterjaap April 9, 2026 10:17

Copilot started reviewing on behalf of jakwinkler April 9, 2026 10:18 View session

jakwinkler force-pushed the v1.14.1 branch from 23f79a7 to 1f62ef0 Compare April 9, 2026 10:20

jakwinkler self-assigned this Apr 9, 2026

Copilot AI reviewed Apr 9, 2026

View reviewed changes

jakwinkler force-pushed the v1.14.1 branch from 1f62ef0 to db01faa Compare April 9, 2026 13:14

peterjaap merged commit 72fbf40 into main Apr 9, 2026
11 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix composer version fallback and self-update binary sync#80

Fix composer version fallback and self-update binary sync#80
peterjaap merged 1 commit into
mainfrom
v1.14.1

jakwinkler commented Apr 9, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Apr 9, 2026

Uh oh!

Copilot AI Apr 9, 2026

Uh oh!

Copilot AI Apr 9, 2026

Uh oh!

Copilot AI Apr 9, 2026

Uh oh!

Copilot AI Apr 9, 2026

Uh oh!

Copilot AI Apr 9, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

-				_ = cmd.Run()
+				if sudoErr := cmd.Run(); sudoErr != nil {
+					fmt.Fprintf(os.Stderr, "warning: failed to sync binary to %s using sudo cp: %v (initial write error: %v)\n", loc, sudoErr, err)
+				}
+			} else {
+				fmt.Fprintf(os.Stderr, "warning: failed to sync binary to %s: %v\n", loc, err)

Conversation

jakwinkler commented Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

jakwinkler commented Apr 9, 2026 •

edited

Loading