ECMAScript Modules #1595

birkskyum · 2022-08-31T11:54:24Z

ESM is the new standard with import/export etc. We don't use it now because there are some old mapbox dependencies that only export .cjs, but nothing more than we can handle. Also, firefox has for 5 years struggled to support this in web workers, and now it's about time to move on:

Firefox (Update: Resolved from v114)

Web worker support ships with Firefox 114 PR, Release notes

The issue was around lack ESM support for web workers: https://caniuse.com/mdn-api_worker_worker_ecmascript_modules
5+ years of ongoing effort: https://bugzilla.mozilla.org/show_bug.cgi?id=1247687

Benchmarks

I once attempted to move the benchmark to ESM #964 , but found the change wasn't backward compatible with the already uploaded benchmarks of prev versions, so it was rolled back #969 .

Point of this issue

This can be a tracking issue where we first map the dependencies we have that aren't compatible, and then keep this updated when they are updated

HarelM · 2022-08-31T12:43:58Z

Do you mean that we currently export maplibre as commonjs and we should export it as esm?
I think the problem of switching out of commonjs besides the FF support was the ability to have the worker URL pushed while building this.
There are some complicated build steps to facilitate for this which I think are very hard to split.
I've looked at this when I tried to understand if we could leverage tree shaking here: #977
I generally think this is a good idea, even better if we can introduce it as part of 3.0 version as a breaking change.
But I'm not sure how to solve all the build complexity with the workers url and also the shared code between the main thread and the worker thread...

birkskyum · 2022-08-31T12:47:28Z

Yes, export maplibre as esm. Sure, I think we might be able to take small steps towards it. A major blocker previously was i.e. also all this node assert that would break the dev build if exported as esm. The first step is likely to have the build as esm.

backspaces · 2022-09-04T21:31:16Z

The published dist/ dir already has multiple versions: https://unpkg.com/browse/maplibre-gl@2.4.0/dist/
And indeed, the individual src files appear use import/export, although "bare".

So shouldn't it be easy to just add a new one: maplibre-gl-esm.js?
And add a "module": "dist/maplibre-gl-esm.js" to package.json?
That seems to be the common approach for folks wanting to support both forms.

For now, skypack works:

        import maplibreGl from 'https://cdn.skypack.dev/maplibre-gl'

.. but we'd like to avoid skypack's conversions which sometimes fail. And it would be nice to use other cdn's as well.

geraldo · 2022-09-19T15:23:51Z

import maplibreGl from 'https://cdn.skypack.dev/maplibre-gl'

@backspaces That doesn't work for me:

var map = new maplibreGl.Map()

gives me an [ERR_UNSUPPORTED_ESM_URL_SCHEME] error.

backspaces · 2022-09-20T15:34:48Z

Try it using this:

<!DOCTYPE html>
<html>
<head>
    <title>Imports</title>
</head>
<body>
    <script type="module">
        import maplibregl from 'https://cdn.skypack.dev/maplibre-gl'
        console.log('https://cdn.skypack.dev/maplibre-gl', maplibregl)
    </script>
</body>
</html>

geraldo · 2022-09-21T07:41:50Z

Thanks, that works fine when run directly in the browser, and even shows a basic map:

var map = new maplibregl.Map({
	container: 'map',
	style: 'https://demotiles.maplibre.org/style.json',
	center: [0, 0],
	zoom: 0
})

But when I try to run it with node (using this https module loader), new maplibregl.Map does throw an error:

ReferenceError: devicePixelRatio is not defined

birkskyum · 2022-09-21T07:52:58Z

The devicePixelRatio likely fail because there is no device/display. What do you hope to achieve running it in node ? Depending on your use-case, you might want to use the node distribution of maplibre-gl-native instead https://www.npmjs.com/package/@maplibre/maplibre-gl-native

geraldo · 2022-09-22T14:15:48Z

The use case would be including Maplibre as dependency, for example offering a maplibre renderer in Maputnik or other kind of web apps depending on Maplibre. So it still would be web and not Android nor iOS, that's why I think using maplibre-gl-native would not work right?

birkskyum · 2022-09-22T15:11:03Z

If it's rendering the vector map in the browser, gl-js is the place to go. If it's server-rendering, the gl-native can be used.

birkskyum · 2023-06-12T09:58:48Z

Related to maplibre/maplibre#159 through tree-shaking

HarelM · 2024-03-06T09:19:15Z

I have made a lot of change in version 4 and basically removed the global object that existed before.
It might be interesting to try out again to export the library in both esm and common js.

HarelM · 2024-05-10T11:36:32Z

The article which I'm looking at right now is the following:
https://www.sensedeep.com/blog/posts/2021/how-to-create-single-source-npm-module.html

Since we add a package.json file to dist folder in order to force bundling tools to treat maplibre as common js I think we'll need to place the esm output in a folder called mjs or something to avoid it being treated as commonjs.

I'll do some experiments locally and see if I can get to a working version or not.
Since this is not a replacement and only an addition there's no breaking change (hopefully) and I'll be able to push it to a regular version and not a breaking change version. later on we can decide if and when to deprecated commonjs build output.

geraldo · 2024-05-10T12:33:05Z

Seems to work now as recent Maputnik versions (v2.0) use MapLibre 4.1.2 as dependency.

HarelM · 2024-05-12T10:15:46Z

Below is a link to an article on esm with rollup and worker configuration:
https://justinribeiro.com/chronicle/2020/07/17/building-module-web-workers-for-cross-browser-compatibility-with-rollup/
This is to overcome the amd usage for the code to load it to the worker.
The above suggest to export the worker code as text - which means no reuse of shared code between the worker and the main thread.
If there's no code sharing then the csp approach is probably better.
Seems like esm and loading the worker code automatically are contradicting one another.
So the current build configuration is the best solution as far as I understand from bundle size perspective.
We might consider introducing esm to the csp build, but this will have very small impact as I believe most users are not using the csp build.

If anyone has more information on this or knows this topic more than I do please feel free to let me know.

HarelM · 2024-05-12T13:22:09Z

@timocov sorry to tag and feel free to unsubscribe, but it would be great if you can take a peak at this and let me know if I'm missing anything - I know you have a lot of knowledge/experience around rollup, build, esm, commonjs amd etc, and any input would be helpful here.

wmertens · 2024-09-11T08:47:34Z

Am I understanding correctly that most of the code size is inside the worker? And that all of the code is used?

In that case ESM builds wouldn't make much of a difference.

It would be different if lots of worker code is not used, in that case it would be better to use dynamic imports and a cjs build for it, but still not ESM.

If most of the code size is on the main thread, ESM would help.

HarelM · 2024-09-11T22:10:53Z

There's a lot (I think) of shared code between the workers and the main thread, which is what the current build try to improve in terms of package size - i.e. pack the shared code once to be used by both the worker and the main thread without increasing the package size.

birkskyum · 2024-12-26T00:25:26Z

@HarelM , I think the situation has developed quite a lot since the article you linked here was written in 2020. As the article states few sections down "All things equal if we ran this in Chrome we’d be golden and we’ve have a magical day.". Thing is, both safari (2021) and firefox (2023) have stabilized support for esm modules in workers since, so now we're close to a point where esm can simply be used throughout.

The current support levels for esm modules in workers is tracked here - I'm not sure how high it needs to be, but it's steadily growing. ESM won't make it into v5 anyways, adding at least half a year till next major, and we have blockers still with indeterminate timelines (#4735), so when we're technically ready, we might re-assess the esm support level, which if sufficient could save the majority of trouble outlined in the bundling article.

HarelM · 2024-12-26T18:29:19Z

@birkskyum is there a progress in the area of sharing code between worker thread and main thread with esm? I can't find anything on that...
If so, can you link to an article that shows how to achieve it?

birkskyum · 2024-12-26T18:46:53Z

Progress? I'm not familiar with any ongoing work on browser apis in that direction.

I don't think the ESM modules will make code sharing between worker/main better or worse - is there any problem with the current rollup bundle split strategy of client/worker/shared? and how does that relate to the module format?

wmertens · 2024-12-26T18:49:25Z

@birkskyum I wonder if bundle size would be smaller with ESM if you're not using summery features?

HarelM · 2024-12-26T19:28:10Z

is there any problem with the current rollup bundle split strategy of client/worker/shared? and how does that relate to the module format?

It's not that there is a problem, but as far as I understand, the code sharing that is performed right now can't be achieved with esm.
This might have changed since I wrote the comment above, so I asked if there was a progress in this aspect in respect to esm.

birkskyum changed the title ~~ECMAScript~~ ECMAScript Modules Aug 31, 2022

geraldo mentioned this issue Sep 19, 2022

import as node module fails #1667

Closed

HarelM added enhancement New feature or request PR is more than welcomed Extra attention is needed labels Oct 21, 2022

birkskyum mentioned this issue Dec 18, 2022

Bump rollup from 2 to 3 #1949

Merged

dbauszus-glx mentioned this issue Sep 1, 2023

Bump Maplibre skypack import to v3.3.1 GEOLYTIX/xyz#901

Merged

birkskyum mentioned this issue Mar 6, 2024

publish to JSR #3804

Open

HarelM mentioned this issue Mar 19, 2024

[typescript] import { Map } from maplibre-gl gives error 'cannot find Map' in browser #3855

Closed

maplibre deleted a comment from unphased Jun 13, 2024

birkskyum mentioned this issue Jun 15, 2024

Use a modern moduleResolution strategy #4275

Closed

birkskyum mentioned this issue Aug 10, 2024

Use moduleResolution: Bundler #4533

Merged

1 task

birkskyum mentioned this issue Aug 21, 2024

Add amd wrapper to fix esbuild plotly/plotly.js#7122

Merged

This was referenced Sep 6, 2024

Future: Move bundling from Rollup to Rolldown #4669

Open

Use platform consistently instead of jest done #4684

Merged

This was referenced Sep 20, 2024

Replace Jest with Vitest 2 #4728

Merged

Bump majors of point-geometry, pbf, vector-tile #4735

Open

birkskyum mentioned this issue Nov 4, 2024

Rename adaptive globe to globe-to-mercator maplibre/maplibre-style-spec#878

Merged

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ECMAScript Modules #1595

ECMAScript Modules #1595

birkskyum commented Aug 31, 2022 •

edited

Loading

HarelM commented Aug 31, 2022

birkskyum commented Aug 31, 2022 •

edited

Loading

backspaces commented Sep 4, 2022 •

edited

Loading

geraldo commented Sep 19, 2022

backspaces commented Sep 20, 2022

geraldo commented Sep 21, 2022

birkskyum commented Sep 21, 2022

geraldo commented Sep 22, 2022

birkskyum commented Sep 22, 2022 •

edited

Loading

birkskyum commented Jun 12, 2023

HarelM commented Mar 6, 2024

HarelM commented May 10, 2024

geraldo commented May 10, 2024

HarelM commented May 12, 2024

HarelM commented May 12, 2024

wmertens commented Sep 11, 2024 •

edited

Loading

HarelM commented Sep 11, 2024

birkskyum commented Dec 26, 2024 •

edited

Loading

HarelM commented Dec 26, 2024

birkskyum commented Dec 26, 2024 •

edited

Loading

wmertens commented Dec 26, 2024

HarelM commented Dec 26, 2024

ECMAScript Modules #1595

ECMAScript Modules #1595

Comments

birkskyum commented Aug 31, 2022 • edited Loading

Firefox (Update: Resolved from v114)

Benchmarks

Point of this issue

HarelM commented Aug 31, 2022

birkskyum commented Aug 31, 2022 • edited Loading

backspaces commented Sep 4, 2022 • edited Loading

geraldo commented Sep 19, 2022

backspaces commented Sep 20, 2022

geraldo commented Sep 21, 2022

birkskyum commented Sep 21, 2022

geraldo commented Sep 22, 2022

birkskyum commented Sep 22, 2022 • edited Loading

birkskyum commented Jun 12, 2023

HarelM commented Mar 6, 2024

HarelM commented May 10, 2024

geraldo commented May 10, 2024

HarelM commented May 12, 2024

HarelM commented May 12, 2024

wmertens commented Sep 11, 2024 • edited Loading

HarelM commented Sep 11, 2024

birkskyum commented Dec 26, 2024 • edited Loading

HarelM commented Dec 26, 2024

birkskyum commented Dec 26, 2024 • edited Loading

wmertens commented Dec 26, 2024

HarelM commented Dec 26, 2024

birkskyum commented Aug 31, 2022 •

edited

Loading

birkskyum commented Aug 31, 2022 •

edited

Loading

backspaces commented Sep 4, 2022 •

edited

Loading

birkskyum commented Sep 22, 2022 •

edited

Loading

wmertens commented Sep 11, 2024 •

edited

Loading

birkskyum commented Dec 26, 2024 •

edited

Loading

birkskyum commented Dec 26, 2024 •

edited

Loading