Deno Fresh support for Remotion Player

[damonrand]

Ask

Add (or document) support for @remotion/player
in Fresh. Player is how you embed a Remotion composition in a React/Preact
app and pass runtime inputProps so one composition can render
differently per user/scenario/record. In Fresh + Preact-compat it doesn't
render — the SVG container mounts but stays empty.

Without it, the only path is pre-rendered mp4s. Fine for fixed marketing
assets, kills the runtime-parameterised use case Remotion is best at.

Live evidence

https://skyprospector.com/test-remotion — both delivery options
side-by-side (working static mp4 vs broken Player), with browser-side
diagnostic data printed inline (typeof Player === "object", Player keys
= [$$typeof, render]). Also has the full root-cause writeup, the things
I tried, and possible resolution paths so you don't have to repro
anything to see the shape of the problem.

Root cause (TL;DR)

Player's pre-bundled ESM does var Player = forwardRef(PlayerFn) with
forwardRef from import "react". That import resolves to real
react@19 from npm at runtime, not to the preact/compat alias declared
in deno.json. Real React's forwardRef returns {$$typeof, render}
(an object); Preact's returns a function. Preact silently can't render
the object → empty DOM, no error.

Confirmed in the browser that our island's import "react" correctly
aliases to preact/compat — the aliasing just doesn't propagate to
internal imports of pre-bundled npm packages.

Environment

Fresh 2.3.3, Preact 10.29.1, @remotion/player + remotion
4.0.456, react / react-dom aliased in deno.json to
npm:preact@^10.27.2/compat. Deno (current stable).

Tried (none fixed it): client-only mount via useEffect, Fresh 2.2 →
2.3.3, project-root vite.config.ts with resolve.alias + dedupe +
optimizeDeps.include. Details on the page.

Possible directions

• Fresh's aliasing reaches into pre-bundled npm package internals (likely
  helps other React-ecosystem packages too)
• Upstream Vite fix if it's fundamentally Vite's pre-bundling behaviour
• Documented Fresh workaround (e.g. esbuild rebundle of Player with
  react → preact/compat at bundle time, served from static/)
• First-class Remotion guidance in the Fresh handbook — even just a
  yes/no would help users decide

Happy to open a standalone repro repo, test a patch, or add diagnostics
to the live page if useful.

[bartlomieju]

Thanks for the detailed writeup and the live demo — super helpful.

Fresh already does a few things to make react → preact/compat aliasing work broadly:

1. resolve.alias in the Vite config maps react and react-dom to preact/compat
2. ssr.noExternal: true bundles all deps during SSR so aliases apply
3. Our Deno resolver plugin manually applies resolve.alias before Deno resolution, so even externalized packages go through the alias

The problem you're hitting is that Deno's npm resolution resolves @remotion/player's internal import "react" to the real react package before our Vite plugin's resolveId hook gets a chance to intercept it. Once Deno has resolved it to node_modules/.deno/react@19.x/..., the alias can't kick in anymore.

This is the same class of issue that would affect any npm package with a hard dependency on react that goes through Deno's npm resolver rather than Vite's module graph.

I'll investigate whether we can intercept these sub-imports in our deno plugin's resolve hook (it's possible they're not hitting it at all for nested npm imports). If not, this may need to be addressed upstream in Deno's npm resolution (respecting import map aliases for sub-dependencies).

In the meantime, your instinct about the esbuild rebundle workaround is probably the most reliable path — bundling @remotion/player with react → preact/compat at build time and serving from static/ would bypass the resolution issue entirely.

[lunadogbot]

Thanks for the thorough writeup — that's a solid root-cause analysis.

The behavior you're seeing is largely Vite's optimizeDeps pre-bundling: when Vite pre-bundles @remotion/player (or any npm package that imports react/react-dom), esbuild resolves the bundle's internal import "react" against that package's own node_modules, not against the project-level resolve.alias. So your island gets preact/compat, but the pre-bundled chunk ships real react@19 — which is exactly the divergence your diagnostic page shows.

Two workarounds worth trying in your vite.config.ts:

optimizeDeps: {
  exclude: ["@remotion/player", "remotion"],
}

…so Vite doesn't pre-bundle them at all (slower cold start, but the project-level alias then applies normally).

Or have the alias applied during pre-bundling:

optimizeDeps: {
  esbuildOptions: {
    alias: {
      react: "preact/compat",
      "react-dom": "preact/compat",
    },
  },
}

The second is what most preact-compat-on-Vite setups use. I'd start there.

Whether Fresh should set this esbuildOptions.alias automatically when the user has aliased react→preact/compat in deno.json is a design call for the core team — flagging react-compat and upstream since the underlying behavior is Vite's.

[damonrand]

Brilliant, thanks for the responses, that really helped..
-> Resolution
Fixed by an out-of-band esbuild rebundle of @remotion/player + remotion, with react → preact/compat applied via esbuild's alias at the bare-specifier resolution stage — before any node_modules lookup. The output is a self-contained ESM at static/vendor/remotion-bundle.mjs (~410 KB raw, ~110 KB gz) with preact/compat fused in. Islands consume it via runtime URL import (so Vite never re-processes the bundle and can't re-introduce real React) and mount Player using the bundle's own render + h (host preact won't recognise components made by bundle preact — different $$typeof markers — so the host does the outer container, the bundle does the inside).

demo: https://skyprospector.com/test-remotion