Dynamic `import(t)` in 3.21.0 breaks Metro bundler (Expo web)

[timbtimbtimb]

mapbox-gl-js version

v3.21.0

Browser and version

No response

Expected behavior

mapbox-gl should bundle successfully with Metro (the default bundler for React Native and Expo web), as it did in 3.20.0.

Actual behavior

Web bundling fails because Metro cannot process the variable dynamic import(t) call introduced in 3.21.0 for TileProvider loading in dist/mapbox-gl.js.

Link to the demonstration

No response

Steps to trigger the unexpected behavior

1. Create an Expo app with bundler: 'metro' for web
2. Install mapbox-gl@3.21.0
3. Import mapbox-gl in a .web.tsx file
4. Run expo start --web

Relevant log output

Web Bundling failed 11479ms node_modules/expo-router/entry.js (2318 modules)
 ERROR  Error: node_modules/mapbox-gl/dist/mapbox-gl.js:Invalid call at line 13: import(t)
    at transformJS (/##############/app/node_modules/@expo/metro-config/build/transform-worker/metro-transform-worker.js:337:23)
    at transformJSWithBabel (/############/app/node_modules/@expo/metro-config/build/transform-worker/metro-transform-worker.js:487:18)

[mourner]

Thanks for the report! Yeah, looks like dynamic imports in the bundle are a trouble in more environments than we anticipated. Investigating this internally.

[stepankuzmin]

Looks like Metro does not support dynamic imports at all facebook/metro#52

[stepankuzmin]

After some digging, it appears that Metro doesn't support dynamic imports (facebook/metro#52) and Expo also lacks import.meta.url (expo/expo#30323), which makes it tricky to fix on our side without compromising other environments.

@timbtimbtimb as a workaround, you can try adding a Babel plugin that rewrites the non-literal dynamic import(t) so Metro can process it. No ejecting should be required as far as I know.

// babel-plugin-rewrite-dynamic-import.js:

module.exports = function ({types: t}) {
  return {
    visitor: {
      ImportExpression(path) {
        if (!path.node.source || path.node.source.type !== 'StringLiteral') {
          path.replaceWith(
            t.callExpression(
              t.newExpression(t.identifier('Function'), [
                t.stringLiteral('url'),
                t.stringLiteral('return import(url)')
              ]),
              [path.node.source]
            )
          );
        }
      }
    }
  };
};

Then add ./babel-plugin-rewrite-dynamic-import to plugins in your babel.config.js and restart Metro with clear cache.

Could you try this and let us know if it works?

[pmontp19]

Hitting the same regression on Vite 8 + Rolldown (also reproduces on Vite 8 + the legacy Rollup path). Sharing details in case it's useful for the internal investigation.

Symptom

Uncaught SyntaxError: Cannot use 'import.meta' outside a module thrown from a blob: URL the moment new Map(...) is constructed. Stack trace points at loadTileProvider.

Root cause in the produced bundle

The UMD entry (mapbox-gl/dist/mapbox-gl.js) builds the worker source by string-concatenating its factory:

const n = "self.onerror=...; var sharedChunk={}; (" + shared + ")(sharedChunk); (" + worker + ")(undefined, sharedChunk); ...";
mapboxgl.workerUrl = URL.createObjectURL(new Blob([n], { type: "text/javascript" }));
new Worker(mapboxgl.workerUrl); // classic worker — no { type: 'module' }

Vite/Rolldown rewrites every import() it encounters into a __vitePreload wrapper that takes import.meta.url as its third argument:

// loadTileProvider in the bundled output
let i = __vitePreload(() => import(t).then(...), [], import.meta.url).finally(...)

("+worker+") invokes Function.prototype.toString() on the factory, which faithfully preserves the import.meta.url literal. The blob is then handed to a classic Worker and the browser refuses to parse it.

So same shape as #13650: a transform that's invisible to mapbox runs over the factory before it's stringified, and the resulting code is no longer valid in a classic worker.

Repro

• mapbox-gl@3.21.0 (3.20.x is unaffected — loadTileProvider is the first dynamic import() inside the worker factory)
• vite@8.0.8 with default config (Rolldown is bundled; same outcome with the Rollup path)
• Default mapbox-gl/dist/mapbox-gl.js UMD entry
• Any page that instantiates a Map

Why per-bundler escape hatches don't help

Vite's only opt-out for __vitePreload wrapping is a /* @vite-ignore */ magic comment placed inside the import() call (vitejs/vite#16241). That's unreachable from userland because the offending import(t) is inside vendor UMD source.

Workaround we're using

Switching to the CSP build (mapbox-gl/dist/mapbox-gl-csp + mapboxgl.workerClass) sidesteps the issue entirely — that path doesn't stringify functions, so Vite's transform stays harmless. It works, but it's a non-trivial migration step for every consumer just to keep parity with the default UMD.

Suggestion

The Babel-plugin workaround posted earlier (new Function('url', 'return import(url)')(url)) would need to ship inside mapbox itself for UMD consumers. Even a build-time guard that emits the dynamic import via a Function constructor only when the UMD target is selected would unblock Vite/Rolldown and Metro without affecting the ESM build.

Happy to provide a minimal Vite repro repo if helpful.

[mourner]

@pmontp19 this is a different issue — can you please the latest stable (v3.23.1)?

[pmontp19]

Thanks for the quick reply. Right, fair distinction, our failure is a different symptom than the original Metro report. Tested 3.23.1 just now (fresh install, fresh build) and our case still reproduces. Sharing details so you have them on file.

Bundler: Vite 8.0.8 with Rolldown (default for Vite 8). Source from 3.23.1:

const i = import(/* webpackIgnore: true */
                 /* @vite-ignore */
                 t).catch(...)

Built output (the vendor-mapbox chunk):

let i = a(() => import(t), [], import.meta.url).catch(...)

a is __vitePreload. Rolldown wraps the import() despite /* @vite-ignore */. Because aU ships in the shared factory and the UMD does ("+shared+")(undefined, sharedChunk) to assemble the worker source, that import.meta.url literal lands in a classic Worker blob and the browser refuses to parse it: Cannot use 'import.meta' outside a module.

So 3.23.1 unblocks webpack (/* webpackIgnore: true */ is honored) but not Vite 8 + Rolldown. Not asking you to do anything else here — this seems a Rolldown bug, not a mapbox-gl one. I'll file it on the Rolldown side and close the loop. Posting the trace in case it's useful when others land on this thread.

[mourner]

@pmontp19 can you also try the new ESM bundle, e.g. import mapboxgl from 'mapbox-gl/esm'? Curious if this can solve your bundling issues — we have put some work recently into making sure it's bundler-friendly (along with some other improvements we'll talk about publicly later).

[dadebue]

FYI: importing from 'mapbox-gl/esm' fixes the issue on my setup (which failed to build when importing from 'mapbox-gl'):

• mapbox-gl 3.23.1
• @sveltejs/kit 2.57.1
• "@sveltejs/adapter-node 5.5.4
• @sveltejs/vite-plugin-svelte 7.0.0
• vite 8.0.9

[pmontp19]

@mourner tested it, mapbox-gl/esm works cleanly on Vite 8.0.10 + Rolldown. 🎉

Standalone reproducer: fresh Vite 8 project, import mapboxgl from 'mapbox-gl/esm', vite build. Vite emits the worker as its own chunk and the main bundle does:

new Worker(
  new URL("/assets/worker-XYZ.js", "" + import.meta.url),
  { type: "module" }
)

grep -c "import.meta" on every produced chunk returns 0 except the main one (where it's a legitimate module-context use). aU lands in the main bundle so even though Rolldown still wraps the dynamic import with __vitePreload(fn, []), it's harmless — no third import.meta.url arg this time, no function-stringification trick.

Migrating our 4 mapbox-gl import sites to the /esm subpath now and dropping the 3.20 pin. Thanks for the steer, much appreciated ❤️