Studio Laravel Package

Technical Evaluation

Architecture fit

• cnvs/studio is not a standalone editor library; it is the companion frontend for Canvas (cnvs/canvas), a Laravel publishing platform by the same author. It is best understood as the authoring/editor UI layer of a single, opinionated application, not a reusable component.
• Fit is therefore binary: high if the roadmap is "run Canvas as our publishing/CMS surface," near-zero if the intent is to embed a Medium-style editor into an existing Laravel product with a different content model, auth guard, or routing convention.
• It assumes Canvas's Eloquent models (posts, users, tags), its admin middleware, and its API endpoints. Those are coupling points, not adapters — every Canvas schema or contract change is a potential Studio break.

Integration feasibility

• Installation is Composer-based and typically transitive: Canvas declares Studio as a dependency, so a normal Canvas install already ships it. A deliberate standalone install requires replicating Canvas's schema, auth, config, and route registration — high effort, low payoff.
• Expect published config plus published frontend assets (Vue-based SPA bundle), route registration under a package prefix, and reliance on the host app's asset pipeline and auth guard. No independent persistence layer is expected.

Technical risk

• Registry signals are weak and inconsistent. Zero dependents is implausible for a package that Canvas would require; treat the star/score/dependent figures as a data-completeness caveat rather than proof of abandonment, and verify against Packagist and the Canvas composer.json before drawing conclusions.
• Single-maintainer bus factor. Same person owns Canvas and Studio; a lapse affects both simultaneously.
• Version coupling. Studio is only as stable as the Canvas release you pin; a Studio minor may require a Canvas major.
• Editor security surface. Rich-text editing means stored HTML — sanitization and paste-handling policy must be owned by us, not assumed from the package.
• Frontend toolchain risk. A bundled Vue SPA means Node/build-tooling drift (Vite vs Mix, Vue 2 vs 3) can break deploys independently of PHP.

Key questions

1. Which Canvas major/minor does this Studio tag target, and is that pairing documented?
2. Does Studio carry its own migrations, or does it read Canvas tables directly?
3. What is the auth/authorization contract — does it reuse the host guard and policies, or define its own middleware?
4. Is the frontend shipped pre-built, or must we run a Node build in CI?
5. What is the current maintained branch, last release date, and posture on security reports?
6. If we must fork, how large is the surface (routes, controllers, Vue components)?

Integration Approach

Stack fit

• Validates cleanly only on the Laravel/PHP versions Canvas supports; confirm php and laravel/framework constraints before committing, since Composer will surface conflicts late and painfully.
• Frontend fit depends on tolerating a Vue SPA inside an otherwise Blade/Inertia/Livewire app; if the product standard is Livewire or React, this is a foreign body.

Migration path

• Greenfield on Canvas: adopt as-is, pin exact versions, treat as vendor code.
• Replacing an existing editor: the real work is content, not code — existing HTML must round-trip through Studio's editor without loss of embeds, code blocks, tables, or media references. Plan a rendering-parity check on a sample of real posts before cutover.
• Non-Canvas host: do not attempt. Cost of adaptation exceeds building on TipTap/ProseMirror directly.

Compatibility

• Pin Studio and Canvas to a tested pair; upgrade them together, never independently.
• Lock the Node version and build image in CI so the asset pipeline is reproducible.
• Verify published assets and config are version-controlled or reproducible, not hand-edited on servers.

Sequencing

1. Spike: install pinned Canvas + Studio, exercise create/edit/publish/embed end to end.
2. Decision gate: fork-and-own vs. consume upstream, based on maintenance signals found in step 1.
3. Content migration dry run with parity diffing on a representative corpus.
4. Feature-flagged rollout behind the old editor; keep a rollback path for one release cycle.
5. Decommission the legacy editor only after parity and sanitization policy are signed off.

Operational Impact

Maintenance

• Budget for the realistic case that we are the de facto maintainer of our fork. Even if upstream is healthy, the version pairing with Canvas means upgrades arrive as a bundle, not a drip.
• Own the HTML sanitization policy and the editor's dependency updates independently of upstream cadence.

Support

• No SLA, no vendor contract; support is GitHub issues and community channels. Escalation path is "we fix it."
• Mitigate by designating an internal owner with commit rights on a fork and a documented patch process.

Scaling

• Server load is ordinary Laravel; the notable vectors are autosave/draft-write frequency and image upload/storage throughput. Rate-limit autosave per user and push media to object storage plus a CDN.
• Client-side: the editor bundle is the heaviest asset in the admin surface; keep it code-split and admin-only so public pages never load it.
• Long posts with many embeds are the realistic performance ceiling — test at the 95th percentile of real content length.

Failure modes

• Silent asset/config drift after an upgrade (published files not refreshed) — surfaces as broken editor styling or 404s.
• Canvas schema change breaking Studio queries — surfaces as editor load failures, potentially data-loss-adjacent if autosave fails silently.
• Auth guard or middleware mismatch after host app changes — surfaces as 403s for legitimate editors.
• CI build break from Node/toolchain drift — blocks all deploys, not just the editor.
• Unsanitized pasted HTML — stored XSS in the authoring surface.
• Upstream abandonment — no security patches; requires fork activation on a known timeline.

Ramp-up

• Engineers need Laravel plus Vue SPA fluency, and must read Canvas internals because Studio's docs are thin relative to its coupling. Assume one to two weeks for a mid-level engineer to be productive, plus a dedicated spike sprint for the TPM/tech-lead to resolve the version-pairing and fork questions.
• Recommend documenting the Canvas↔Studio version matrix and the fork patch procedure in the first sprint; both become expensive to reconstruct later.