`_defineProperty is not defined` after upgrading to maplibre-gl 5.17.0

[gzurbach]

After upgrading maplibre-gl from 5.16.0 to 5.17.0, the application crashes at runtime with the following error when interacting with the map (e.g. zooming):

_defineProperty is not defined

This issue does not occur after downgrading to version 5.16.0.

The error appears to be caused by untranspiled code relying on Babel helpers that are not provided at runtime.

This looks like a packaging / transpilation regression in 5.17.0, where Babel helpers such as _defineProperty are referenced but not included or inlined.

[BRaimbault]

Hi!

I think I have a similar error here. I suspect that the changes in #6983 introduced usage of modern class fields and private methods, which require ES2022+ and could be the cause.

[HarelM]

Can you find the PR that caused this? I don't have a good way to reproduce this...
Is it the usage of "..." that's causing this?

[HarelM]

Also probably similar to this one:

• 'ReferenceError: Can't find variable: __publicField' when using Vite #6680
• 5.7.2 gives error: __spreadProps is not defined #6429

[wayofthefuture]

@BRaimbault Can you be more specific about #6983? I don't see anything in this PR which has not already existed in Maplibre prior.

[neodescis]

@HarelM: Should we define what bundlers we want to support, and create some build+run tests using them? It might take some doing (and some maintenance), but I think it would prevent these problems in the future.

[neodescis]

@BRaimbault Can you be more specific about #6983? I don't see anything in this PR which has not already existed in Maplibre prior.

Nothing jumps out at me in this PR either, but keep in mind that it's only the worker thread that doesn't get these bundler-introduced functions, since the bundler doesn't know how to add them to the blob-ified script.

[HarelM]

It might be enough to define some linting rules maybe... IDK... we need to add some safe guards...

[HarelM]

It might be the "...", but it was not introduced in this PR, I think.

[BRaimbault]

I spent some time digging deeper but wasn’t able to reach a definitive conclusion. I may have been too hasty in pointing at #6983. _dispatchWorkerUpdate and _updateWorkerData do appear in my __publicField is not defined error trace, but I don’t have enough evidence or time to firmly link them.

For now, I’ve set my Vite build target to es2022, which should work for my userbase.

[HarelM]

@BRaimbault can you fork this and remove the private modifiers from geojson to see if this solves this issue? I can create a build which doesn't use these, although I do want to encourage people to use those when opening PRs...

[claudiobgit]

Root cause analysis

I traced this to the worker-via-string pattern in maplibre-gl's UMD bundle.

How the worker is created

In dist/maplibre-gl.js, MapLibre creates the Web Worker by serializing module functions as strings:

var workerBundleString = 'var sharedModule = {}; (' + modules.shared + ')(sharedModule); (' + modules.worker + ')(sharedModule);'

Why this breaks with esbuild/Vite

1. maplibre-gl v5.17+ introduced native class field declarations in the UMD bundle (20 classes, e.g. class Kc{options;tileCoords;tiles;stats={...})
2. When a bundler like esbuild (used by Vite) targets < ES2022, it transforms class fields into helper calls: __publicField(this, "options")
3. The __publicField helper is defined in the module scope (ESM top-level)
4. MapLibre serializes internal modules with modules.shared.toString() — this captures the function body but loses the reference to __publicField in the outer scope
5. When the serialized code executes in the Web Worker, __publicField is not defined → runtime error

Evidence

In Vite's pre-bundled output (node_modules/.strapi/vite/deps/):

• chunk-LK32TJAX.js defines and exports __publicField
• chunk-M3XNOQFI.js imports __publicField at the top, but the 54 usages are inside the UMD factory wrapped in __commonJS()
• The worker receives the serialized function body without the helper → crash

How Mapbox solved this

Mapbox-gl-js had the same issue (mapbox/mapbox-gl-js#12656). They fixed it by:

1. Removing all post-ES2020 syntax (class fields, private methods) from the bundle
2. Adding an ESLint rule to prevent reintroduction

Suggested fix

Either:

• Remove class field declarations from the 20 affected classes in the UMD bundle (replace with constructor assignments), similar to what Mapbox did
• Or ensure the worker bundle string includes the necessary helpers when class fields are present

Affected versions

• Works: maplibre-gl 5.16.0 (no class fields in UMD)
• Broken: maplibre-gl 5.17.0+ (class fields introduced via @maplibre/mlt and other changes)
• Bundler: Any bundler targeting < ES2022 (esbuild via Vite, Webpack with Babel, etc.)
• Workaround: Set bundler target to es2022 so class fields pass through untransformed

[HarelM]

Thanks for the extra info. Do you know which classes are those that cause this issue? As a stop gap we might be able to fix it.