>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3588661. --> Reported by: [balintbrews](https://www.drupal.org/user/613760) Related to !1063 >>> <h3 id="overview">Overview</h3> <p><code>canvas build</code> and <code>canvas push</code> should use a Canvas-specific Vite build instead of a separate command-level bundling pipeline that only uses Vite in isolated places.</p> <p>The current build flow is too bespoke. Build behavior is split across CLI commands and package-specific code paths, which makes it harder to keep CLI builds, pushes, and Workbench previews aligned. It also limits support for common Vite-resolved code patterns in local Code Components.</p> <p>This should add support for local build capabilities such as static asset imports, SVG React component imports with <code>?react</code>, and consistent asset manifest entries for pushed components.</p> <p>The goal is to preserve the current external contract while changing the internal build architecture. Existing CLI options, <code>dist</code> output, <code>canvas-manifest.json</code>, component payloads, and backend API behavior should continue to work.</p> <h3 id="proposed-resolution">Proposed resolution</h3> <p>Add a shared Vite compatibility and build layer in <code>packages/vite-compat</code> for Canvas host projects. This layer should own Canvas component resolution, host aliases, externals, asset handling, and component-oriented build metadata so the CLI and Workbench build components consistently.</p> <p>Refactor <code>packages/cli</code> to use one canonical <code>buildCanvasProject()</code> service for both <code>canvas build</code> and <code>canvas push</code>. <code>canvas build</code> should write the current <code>dist</code> output, and <code>canvas push</code> should consume the same structured build result instead of rebuilding components or rereading <code>dist</code> through a separate path.</p> <p>Let Vite own the browser graph, artifacts, chunks, and asset mappings wherever possible. Keep explicit AST scanning only for backend metadata that is not a bundler concern, including imported Canvas component dependencies, data dependencies, and any other metadata required for push ordering or backend payload assembly.</p>