Statamic 3D Field Laravel Package

Product Decisions This Supports

• Platform upgrade sequencing. Release 1.1.0 widens statamic/cms to ^5.0|^6.0, which is the gating signal that this addon will not block a Statamic 6 migration. If Statamic 6 is on the roadmap, this package moves from "unknown" to "cleared for the upgrade train" — the remaining dependency question is the rest of the addon portfolio, not this one.
• Build vs. buy for 3D asset handling. It supplies a Control Panel fieldtype — the editor-facing widget for picking/previewing 3D models via the model-viewer web component — not a storage layer, transcoding pipeline, or CDN strategy. Buy this; build the asset pipeline separately.
• Scope containment for 3D/AR content features. Enables a narrow, reversible experiment: expose a model-viewer field in a collection or Globals and see whether editors actually use 3D assets in product or marketing entries before committing to a broader 3D content initiative.
• Roadmap signal on maintenance posture. The release is a framework-compatibility port, not a feature release. That is a positive maintenance signal (the maintainer is tracking upstream majors) but it also tells you the addon's velocity profile: expect compatibility work, not new capability. Plan feature bets elsewhere.
• Not a decision driver: the internal changes (FieldtypeMixin banner shim, externalized Vue, IIFE bundle) are implementation detail with no product-facing delta. Do not let them appear as value in a roadmap narrative.

When to Consider This Package

Consider it when:

• You are on Statamic 5 or 6 and want 3D model preview in the Control Panel without writing a custom fieldtype — the model-viewer custom element registration and CP integration are already handled.
• You are planning a Statamic 6 migration and need the addon dependency list to be green. The widened constraint is the specific thing to verify in composer.json.
• Your 3D usage is presentational — product turntables, AR-preview-able models, GLB/GLTF assets served from the assets container. You are not asking the addon to validate, transcode, or optimize models.
• You want a low-commitment pilot: one field, one collection, measurable editor adoption.

Look elsewhere or wait when:

• You need a full 3D pipeline. Model conversion, LOD generation, Draco/mesh compression, poster-frame rendering, CDN delivery, and file-size guardrails are not in scope here and won't be.
• You need AR placement on mobile. model-viewer provides some of this at the browser layer, but the addon gives no control over which capabilities are enabled or how they degrade — evaluate the underlying web component directly, not the fieldtype.
• You require vendor risk documentation. The release notes give no information on test coverage, licensing terms, maintainer count, or a security disclosure path. Absent that, treat it as a single-purpose utility rather than infrastructure, and require engineering sign-off before it lands in a client deliverable.
• You are running a dual-Statamic fleet. The release claims Statamic 5 compatibility, but 5 and 6 ship different Control Panel Vue runtimes (2 vs. 3), and this build targets Vue 3 with a shim to bridge. That is exactly the configuration where CP regressions hide. If you run both versions in production, demand a smoke-test pass on each before rolling out.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost addon that lets editors attach and preview 3D product models directly in Statamic's admin. The vendor just shipped a compatibility release so it keeps working across the current and next major version of the CMS — meaning it won't become a blocker when we upgrade the platform. It is not a 3D content platform; it is a convenience layer on top of standard model files. Recommend a single-collection pilot with a defined success metric (e.g., percentage of product entries with a 3D model within one quarter) rather than an org-wide rollout. Cost of reversal is one uninstalled package.

To engineering: The 1.1.0 change is a Vue 2 → Vue 3 port of the CP fieldtype to support Statamic 6, with the statamic/cms constraint widened to ^5.0|^6.0. Mechanically: the build moved from @vitejs/plugin-vue2 to @vitejs/plugin-vue, Vue is externalized, output is an IIFE bundle with a FieldtypeMixin banner shim, model-viewer is registered as a custom element in the Vue compiler config, the removed toggle-input global is replaced with ui-switch, illegal this. references are stripped from templates, and the component now registers inside Statamic.booting().

Three things to verify before we depend on it:

1. The shim earns its keep. The IIFE + banner shim is what lets one bundle serve both CP runtimes. Confirm it's maintained upstream and that we're not one Statamic point release away from a silent break.
2. Regression surface is CP-only but real. Field preview, drag/drop, and save behavior are the likely failure points. Run the same manual checks on Statamic 5 and 6.
3. Supply-chain basics. Pin the version in composer.json, confirm the model-viewer custom element is loaded from a versioned source rather than a floating CDN URL, and check whether the asset is bundled or fetched at runtime — that difference affects our CSP and offline/air-gapped behavior.

Overall: adopt for a scoped pilot; do not treat it as a platform dependency until we have the above answers.