With that change we could also remove the preprocessors for Firefox?

With that change we could also remove the preprocessors for Firefox?

Yeah. I've removed them.

The down side of this approach is, that for the not bundled version, the version is always latest.
At the moment the version in package.json will be modified with a new release and is then exported for the unbundled version too.

Yeah, true. I've amended this PR and search and replace version = 'latest' with version = 'x.y.z' if process.env.NODE_ENV === 'release'.

@simon04 did you push? I don't see any changes

Err, not to this branch (was considering a separate branch for a moment). Pushed now.

Sorry for the ping @jonkoops @IvanSanchez @mourner - I’d like to proceed with version 2.

@Falke-Design @simon04 Please remind me - what's the rationale for ditching the current rollup plugins approach? Compatibility issues with 2025 toolchains?

I'm kinda against using latest, as I'd prefer the git commit hash in that scenario.

Hi, see #9609 (comment). At the moment, the entire content of package.json ends up in the dist bundle.

@IvanSanchez the goal would be to be able to access the classes directly without the bundle.
With the current approach, loading the package.json and export version we add the whole package.json to the bundle: #9609 (comment)

I don't like "latest" that much either. We could always overwrite the version variable with the actual version and commit it

I'd rather have something like __LEAFLET_VERSION__ as the placeholder string.

Also, can you folks try out if the namedExports option of the JSON rollup plugin ( https://github.com/rollup/plugins/tree/master/packages/json#namedexports ) would solve the "whole package.json in bundle" issue?

The named export was in use prior to #9609. But browsers (running the non-bundled code while testing) do not support named imports, see #9609 (comment).

Thanks for the suggestion but I just merged #9717