Repository navigation
studio: GSAP plugins are loaded from cdn.jsdelivr.net at runtime (offline / no third-party requests) #6205
Description
Summary
The studio/preview loads GSAP plugins from cdn.jsdelivr.net at runtime: packages/core/src/gsapCdn.ts builds https://cdn.jsdelivr.net/npm/gsap@<version>/dist/... (default 3.15.0) and motionPathPluginUrl(). Opening the editor requests MotionPathPlugin.min.js from jsDelivr.
Why it matters
- Offline or restricted-network setups cannot load the plugin.
- Privacy-restricted environments do not want third-party requests from a local editor.
- It mirrors the issue fixed for pr-to-video in pr-to-video: assemble-index.mjs hardcodes the jsDelivr CDN for GSAP (breaks offline / restricted-network renders) #6028.
Suggestion
Serve GSAP and its plugins from the locally installed package (the CLI already ships them for renders), or allow a local base URL via config/env, e.g. HYPERFRAMES_GSAP_BASE_URL.
Observed on 0.8.97; same code on main / v0.8.191.
Activity
jrusso1020 commentedon Oct 24, 2026
Thanks, confirmed on current main. packages/core/src/gsapCdn.ts:3-11 builds a fixed cdn.jsdelivr.net URL with no override. Studio preloads MotionPathPlugin from it on every preview load (packages/studio/src/components/nle/NLEContext.tsx:148, which calls packages/studio/src/utils/gsapSoftReload.ts:89), even when the composition never uses a motion path. That means offline setups can't load the plugin, and every editor open makes a third-party request whether or not the project uses the CDN. Serving the plugin from the locally installed gsap package, or adding a base-URL override like the one you suggest, would fix both. — Rames
feat(studio): load GSAP from the CLI's bundled copy by default
fix(studio): load GSAP core when only a GSAP plugin is on the page (h…
feat(studio): load GSAP from the CLI's bundled copy by default (heyge…