fix(nginx plugin): place mime.types next to nginx.conf so include resolves

[mikeland73]

Summary

Fixes #2908.

The nginx plugin currently fails to start because it cannot find its mime.types file:

[emerg] open() ".../devbox.d/nginx/mime.types" failed (2: No such file or directory) in .../devbox.d/nginx/nginx.conf:6

Root cause: PR #2844 added include mime.types; to nginx.conf and created the mime.types file at {{ .Virtenv }}/mime.types (.devbox/virtenv/nginx/mime.types), under the assumption that nginx -p $NGINX_PATH_PREFIX would make the relative include resolve against the prefix path. In fact nginx only uses the -p prefix for runtime paths (error_log, access_log, root, …); at configuration time, relative include paths are resolved relative to the nginx.conf file itself, which devbox places in the DevboxDir (devbox.d/nginx/).

Fix: Create mime.types in the DevboxDir alongside nginx.conf, so the relative include mime.types; resolves correctly. This mirrors how the plugin already handles fastcgi.conf (also created in DevboxDir). The plugin version is bumped 0.0.5 → 0.0.6 to follow the existing convention (PR #2844 bumped 0.0.4 → 0.0.5).

-    "{{ .Virtenv }}/mime.types": "nginx/mime.types",
+    "{{ .DevboxDir }}/mime.types": "nginx/mime.types",

Scope: fresh installs vs. existing environments

This fix applies automatically to fresh installs of the nginx plugin (new projects, or projects with no prior nginx lockfile entry) — the relocated mime.types is created next to nginx.conf and the include resolves.

It does not auto-remediate environments that already installed the plugin (i.e. anyone already affected by #2908). Devbox intentionally treats files under devbox.d/ as user-owned and never overwrites them once the plugin is recorded in devbox.lock: shouldCreateFile (internal/plugin/plugin.go:233) returns false for any devbox.d/ path when PluginVersion != "", and this check is not gated on a version change — so the version bump alone does not force regeneration. (The same limitation applied to PR #2844's original change.)

Manual remediation for existing broken environments: remove the plugin's materialized config dir and reinstall, e.g.

rm -rf devbox.d/nginx
devbox install

The stale .devbox/virtenv/nginx/mime.types from 0.0.5 is harmless — nothing references it after this change.

How was it tested?

• Verified plugins/nginx.json remains valid JSON.
• Traced the file-placement logic: nginx.conf is created at {{ .DevboxDir }}/nginx.conf and uses a relative include mime.types;; placing mime.types in the same DevboxDir makes the include resolvable. The fastcgi.conf file already follows this exact placement pattern.
• Traced CreateFilesForConfig / shouldCreateFile in internal/plugin/plugin.go to confirm fresh installs create the file (all devbox.d/nginx/ files are only created because a fresh install has no locked PluginVersion) and to characterize the existing-environment behavior documented above.
• No other references to the {{ .Virtenv }}/mime.types path exist in the codebase, and the nginx env.test.txt testscript does not assert on the mime.types location, so behavior is unchanged apart from the fix.

cc @jefft (issue reporter)

Community Contribution License

All community contributions in this pull request are licensed to the project
maintainers under the terms of the
Apache 2 License.

🤖 Generated with Claude Code

https://claude.ai/code/session_013yJQ9FtijMB9SfnTeRVC1P

[Copilot]

Pull request overview

This PR fixes the nginx plugin startup failure caused by include mime.types; being resolved relative to the generated nginx.conf location (in devbox.d/nginx/), while mime.types was previously created under the virtenv prefix.

Changes:

• Bump nginx plugin version from 0.0.5 to 0.0.6 so existing environments pick up the fix.
• Relocate mime.types creation from {{ .Virtenv }} to {{ .DevboxDir }} so include mime.types; resolves during config parsing.

---

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

[mikeland73]

@claude ptal

[claude]

Claude finished @mikeland73's task in 42s —— View job

---

Review: PR #2929 — fix(nginx plugin): place mime.types next to nginx.conf

• Gather context (PR description, diff, review comments)
• Inspect plugins/nginx.json and related plugin logic
• Verify version-bump mechanics regenerate create_files for upgrading environments
• Post review feedback

Root-cause diagnosis and the DevboxDir/Virtenv distinction are correct. nginx.conf and nginx.template (plugins/nginx/nginx.conf:6, nginx.template:6) both use a bare relative include mime.types;, and nginx.conf itself is created at {{ .DevboxDir }}/nginx.conf. nginx resolves config-time include relative to the config file's own directory, not the -p prefix, so moving mime.types from {{ .Virtenv }} to {{ .DevboxDir }} (mirroring fastcgi.conf, which already lives there) is the right fix conceptually.

However, there's a real problem with the claim that "the plugin version is bumped 0.0.5 → 0.0.6 so existing environments pick up the relocated file." I traced the file-creation gating logic in internal/plugin/plugin.go:

• CreateFilesForConfig (line 73) calls shouldCreateFile (line 233) for every create_files entry.
• shouldCreateFile (lines 239–243):

  pluginInstalled := pkg != nil && pkg.PluginVersion != ""
  if strings.Contains(filePath, sep+devboxDirName+sep) && pluginInstalled {
      return false
  }

  Any path under devbox.d/ is never (re)created once the plugin is already recorded in devbox.lock (i.e. PluginVersion != "") — this check only tests for non-empty, not for a version mismatch against cfg.Version.
• I grepped the whole repo for PluginVersion (internal/plugin/plugin.go:119,240, internal/lock/package.go:19, internal/boxcli/multi/sync.go:47) — nowhere is the locked version compared against the plugin's declared version. The version bump is otherwise inert; it's stored in the lockfile but never used to trigger regeneration.

Net effect: for a project that already has the nginx plugin installed (i.e. exactly the reporter's scenario in #2908, and anyone else who already hit this bug), devbox.lock already has plugin_version: "0.0.5", so pluginInstalled is true, and the new {{ .DevboxDir }}/mime.types entry will be silently skipped forever — devbox update/reinstalling packages/upgrading devbox will not create the file for them. Only genuinely fresh installs (no prior lockfile entry for nginx) get the fix automatically. The stale .devbox/virtenv/nginx/mime.types is harmless (nothing references it anymore), but the real fix never lands for upgraders without a manual step.

Suggestion: either

1. Call out a manual remediation step for existing users in the PR/release notes (e.g. delete devbox.d/nginx/mime.types's directory or the plugin's lockfile entry and rerun devbox install), since devbox.d files are intentionally treated as user-owned/never overwritten once installed, or
2. If forced regeneration is desired, that requires a code change to shouldCreateFile to special-case a version bump — a bigger change than this PR intends, and one that would need care since it currently protects user customizations to files like nginx.conf/nginx.template in the same directory.

Given the design intent (devbox.d files are never silently overwritten), option 1 is likely the pragmatic path — but the PR description's claim that the version bump alone fixes existing environments should be corrected, either in the PR description or in the implementation.

Fix this →

Everything else checks out: plugins/nginx.json is valid JSON, the fastcgi.conf placement pattern is followed correctly, and no other code references the old {{ .Virtenv }}/mime.types path.
· branch claude/focused-goldberg-umv184

[mikeland73]

Took a look 👀 — status summary:

CI (commit 776a93b):

• ✅ cli-tests — passing
• ✅ Random Reviewer Assignment — passing
• ✅ Copilot Code Review — no change requests (accurate summary of the fix)
• 🔄 Claude Code Review — running (triggered by the ready-for-review transition)

The fix is a 2-line change to plugins/nginx.json: relocate mime.types from {{ .Virtenv }} to {{ .DevboxDir }} so the relative include mime.types; in the generated nginx.conf resolves at config-parse time (nginx only applies the -p prefix to runtime paths, not config-time includes). This matches how fastcgi.conf is already placed, and the plugin version is bumped 0.0.5 → 0.0.6 so existing environments pick up the relocated file. Fixes #2908.

Nothing outstanding to address on my end — mergeable_state is blocked only pending a review approval, not a failing check. Ready for review/merge whenever you'd like.

---

Generated by Claude Code

[mikeland73]

Good catch on the version-bump claim — I traced shouldCreateFile (internal/plugin/plugin.go:233) as well and confirmed it: any devbox.d/ file is skipped once PluginVersion != "", with no version-mismatch comparison anywhere, so the bump doesn't force regeneration for already-installed environments.

I've corrected the PR description rather than changing code:

• Removed the inaccurate "existing environments pick up the relocated file" claim.
• Added a Scope section spelling out that the fix lands automatically on fresh installs, and documented the manual remediation for already-broken environments (rm -rf devbox.d/nginx && devbox install).
• Kept the 0.0.5 → 0.0.6 bump only for convention (matching PR fix(nginx plugin): include mime.types so static files get correct Content-Type #2844), no longer claiming it drives regeneration.

I deliberately did not take option 2 (special-casing a version bump in shouldCreateFile): that touches core logic which intentionally preserves user edits to nginx.conf/nginx.template in the same dir, so it's out of scope for this focused plugin fix. Happy to open a separate issue/PR if maintainers want automatic migration for devbox.d files on plugin version changes.

---

Generated by Claude Code