wheels-sentry ships incompatible package.json and box.json declaring different install locations

[bpamiri]

Severity: low — but creates the SENTRY-B / #2705 breakage when combined with wheels packages add.

Surfaced by: titan Phase 2.1 (Wheels 4.0 upgrade), 2026-05-15.

Description

The wheels-sentry@1.0.0 package ships two manifest files that disagree about where it should be installed:

• package.json (4.0 PackageLoader convention) declares provides.mixins = \"controller\" — implies install to vendor/<name>/ so PackageLoader can pick it up.
• box.json (legacy ForgeBox convention) declares directory: \"/plugins/\" + packageDirectory: \"sentry\" — implies install to plugins/sentry/.

Sentry.cfc:79 hardcodes the plugins.sentry.SentryClient path, so only the legacy install location works. Combined with the fact that wheels packages add installs to vendor/<name>/ (lucli-canonical) and ignores box.json hints, the package is broken at its canonical install path — see #2705 for the symptom.

Suggested fix

Pick one install convention and ship one manifest. Options:

1. Drop box.json — the package is Wheels 4.0+ only, lucli-canonical (vendor/<name>/). Update Sentry.cfc:79 to reference SentryClient.cfc via relative file path so it works wherever installed.
2. Drop the 4.0-shape package.json — keep the legacy box.json, ship as a plugins/-style legacy package only. Note this would foreclose on PackageLoader mixin/middleware integration.

Option 1 is forward-looking; Option 2 is least disruptive.

cc @bpamiri

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

Suspected layer

cli — wheels packages add (lucli-canonical install) is what surfaces the breakage by placing the package at vendor/<name>/, but the defective artifacts (box.json, package.json, Sentry.cfc:79 with the hardcoded plugins.sentry.SentryClient path) live in the external wheels-dev/wheels-sentry repo, not this one. See .ai/wheels/cli/ and CLAUDE.md § "Package System" for canonical install semantics.

Fix sketch

The fix is cross-repo and primarily lives in wheels-dev/wheels-sentry, not here. Two options laid out in the issue body:

1. Drop box.json, keep the 4.0-shape package.json, and rewrite Sentry.cfc:79 to resolve SentryClient.cfc via getDirectoryFromPath(getCurrentTemplatePath()) & "SentryClient.cfc" (forward-looking — keeps PackageLoader mixin integration).
2. Drop the 4.0-shape package.json, keep box.json, ship as legacy plugin only (least disruptive but forecloses PackageLoader integration).

A framework-side mitigation (honor box.json hints in wheels packages add, or auto-create a per-package Lucee mapping at install time) is also discussed in the linked symptom issue #2705 — that change would land here in cli/lucli/services/packages/**.

Confidence: low

The reproducible defect is clear, but the fix shape requires (a) editing an external repo that propose-fix cannot reach and (b) picking between two design options before any code lands. Holding for manual handling.

<!-- wheels-bot:triage:2710 -->
<!-- wheels-bot:triage-class:bug -->

[bpamiri]

Resolved via a third option not listed in the original report:

• wheels-dev/wheels-sentry@83b679e (v1.0.1) — declares "mappings": {"plugins.sentry": "."} in package.json
• #2705 / #2739 — framework support for the plural mappings field in PackageLoader

At boot, plugins.sentry is now registered as a CFML mapping pointing at vendor/wheels-sentry/, so the hardcoded new plugins.sentry.SentryClient(...) call at Sentry.cfc:79 resolves correctly at the canonical lucli install path. No rewrite to a relative path required.

The two manifests still literally disagree about install location, but it's no longer a runtime issue:

• box.json is only consulted by legacy ForgeBox/CommandBox
• package.json is consulted by wheels packages add (lucli-canonical)
• The mapping bridges both — the package works at either location

Closing as resolved. Removing box.json is cosmetic cleanup, not a bug.