Feature roadmap

[daniel-brenot]

What features do we want to see after support has been dropped for Internet Explorer in v2.0?

Please use one comment per feature request if you have multiple feature requests.

[Falke-Design]

Validation of methods arguments

[mathe42]

When we had "offical" types files that would be 100% not needed.

[Falke-Design]

Look into #7128 or a current usecase would be #7432. If a string is used instead of interges the L.Point() calculation goes wrong. But how to check correctly if it is a number? See #7432 (comment)

adds a lot of verbose code

Maybe we should define Validation-Util functions and add them only at certain places.

When we had "offical" types files that would be 100% not needed.

What are "offical" types? We have them already in the documentation but throws no error if the wrong type is passed. Same if TypeScript is not used.

[mathe42]

Typedefs in comment are removed at build. With .d.ts files in npm package (= "offical") users would get autocomplete in there ide. Even js users!

[mathe42]

Some idea: have a dev and a production build. In dev checks are done in prod checks are skiped (and no extra code!)

[mourner]

For simple cases where we get a string instead of a number, we can usually just do +arg. I would definitely not want to clutter the code with a ton of validation utility calls. I agree that a nice strict type coverage can somewhat fulfill the same need in TS codebases.

[Falke-Design]

TypeScript .d.ts file

Very useful would be to refactor Events because there is no easy handling in TypeScript definition. See: geoman-io/leaflet-geoman#893
What we have done in Leaflet-Geoman: leaflet-geoman.d.ts

[mathe42]

I would split the dts files so we have for (some) src files typings. That would imporove ide support while developing leaflet.

[mathe42]

see #7733

[jonkoops]

I am a huge proponent of this feature. It would greatly improve the out of the box experience of TypeScript users and those who simply expect some level of auto-completion in their IDE.

[ryan-morris]

@mathe42 just to clarify, are you saying that events can be done with the EventMapInterface now alongside the existing @types/leaflet, or are you recommending shifting them to that style declaration?

[mathe42]

I think the types from @types/leaflet should be added to this reposetory. The talk about the EventMap is only that @Falke-Design thought that with a change to the Evented class we can get better typings (and much smaller) but this is possible with the "EventMap-Interface"-Syntax.

I'm working on it in #7733.

This would mean that @types/leaflet will become deprecated. But keeping it near the source code means less errors and maintaining them is easier.

[daniel-brenot]

Writing the library using newer ES6 syntax.

[daniel-brenot]

This should still let us support older browsers using rollup to create bundles that work for older or newer versions

[mathe42]

I could not get the current class syntaxt (with no API change) in es6 that can be transpiled to es3 as I needed classinstance.__proto__ or classinstance.constructor.prototype

[mathe42]

Note when dperecating old IE ignore my last comment

[jonkoops]

I think that 'using new ES6 syntax' is too broad, instead we should focus on what features will provide benefits to the community. For example aligning the custom class implementation with standardized classes.

[mathe42]

Maybe a better statement would be allow es6 syntax (and above) in PR and update code where new syntax would make the code more readable.

[Falke-Design]

Polyfill deprecation. Half of the methods in L.Util would go away.

I personal use a lot of L.Util functions because they are clear and easy to read. Maybe we don't need to remove L.Util, we can remove only the polyfills.

[mathe42]

No babel dosen't polyfill back to IE (es3) only to es5.

[daniel-brenot]

I've done this before. I'm currently supporting IE11 on a corporate site

[mathe42]

Yes but IE11 = es5. es3 = IE 7-10

[mathe42]

So with babel you can only suport IE 11 but not older versions

[daniel-brenot]

Aah i see. I didn't think you were talking about 7-10, as it seems everyone is happy not supporting those versions.

[Falke-Design]

Getting rid of global switches (L_NO_TOUCH and L_DISABLE_3D)

[daniel-brenot]

Or produce more bundles. One for older browsers and one for newer. This practice is quite common, and easier to implement since we wouldn't need to write our own polyfills

[mathe42]

Your options requires same code changes as my, just time when code is removed is changed

[IvanSanchez]

Instead of switches, it's currently possible to write values to properties of L.Browser. Feels cleaner to keep allowing this rather than to keep global switches.

[mathe42]

But that would not eliminate dead code.

[IvanSanchez]

On the contrary: L_NO_TOUCH can go away because people can set L.Browser.touch = false. Idem with L_DISABLE_3D and L.Browser.any3d.

[Falke-Design]

Removing CSS 3D acceleration hacks that likely haven't been relevant for years.

[mathe42]

Treeshaking in one of 2 ways:

1. With a lot of API breaking all nested exports e.g. (L.Controls....) has to get "top level exports" (this can be done in a "friendly" way where Plugins only habe to run a codemod to change Im/Exports)
2. With more switches for example L_NO_POLYGON that can be set to true at build time of the users of this lib

Why?

If you look at

Leaflet wants to be modular (what it is not currently) and small (for what it does is 40K not much but it is a big lib!) and treesaking would help with both.

[mathe42]

Just thought about it 1. can be done without breaking change if we keep the current export but add for evrything a "top level export" no codemod required.

For users who don't use a bundler the filesize would increase a little.

[Falke-Design]

Moving mixins added through L..include(...)
Eliminating the use of side effects code across classes — e.g. moving mixins added through L..include(...) in favor of having them inline

[mathe42]

1. This will also remove all (or near all) Sideeffekt code from modules (So code that runs and does something outside the file at import of that file). That is good.
2. Should include be deprecated and removed in a later version?

[Falke-Design]

I really like the behaviour and functions of extend and include, it would be nice for plugins if they are not removed

[mathe42]

Was just wondering.

[Falke-Design]

Stale Bot

[mourner]

This one is not dependent on a major version, we can add it at any time.

[daniel-brenot]

Making leaflet not expose "L" to the global scope unless imported as a script tag in the webpage.
https://www.w3.org/wiki/JavaScript_best_practices#:~:text=a%20good%20thing.-,Avoid%20globals,are%20an%20incredibly%20bad%20idea.&text=If%20you%20have%20global%20variables,will%20overwrite%20your%20variables%2Ffunctions.

[Falke-Design]

Changing the line endings CRLF / LF to the same for all files.
#7409
This is will break some PR because they have some files with the wrong line break. BUT it would be possible to change all existing PRs because the maintainers has mostly the permission to edit the PRs.

So my suggestion (after we reduced the PRs a lot):

1. Freez PRs
2. make a branch with where all files have the same line break (or directly in the master)
3. update each PR from a maintainer and check if it works when comparing against the new branch. On a weekend I can do this and change each PR but I would need write access for this.
4. merge the branch into the master

[Falke-Design]

And converting smart-tab to 4-spaces: #3870

[Malvoz]

Use the document's normal font size on leaflet-container: #8051

[dolorain]

support vector tilelayer

[iamtekson]

I found this interesting research. In this research, they compare the performance of three different popular open-source libraries, i.e. leafletjs, OpenLayers and maplibre. The result of this paper was quite surprising to me. The leaflet has the worst performance. Mainly they tried to load the vector tiles using the vectorGrid plugin. I think v2.0 should address this issue properly and load the vector tile layer in a faster way. Looking forward to seeing this feature in the v2.x.x.

The summary of the research that I mentioned above is here:

[ansh-ag]

map rotation

[Malvoz]

Relevant info from https://github.com/Raruto/leaflet-rotate:

Initially based on the work of Iván Sánchez Ortega (see: #268)

[ansh-ag]

The plugin is okay, but its not as smooth as it should be. I dont remember correctly but there was a leaflet fork which had map rotation from few years, we used it to create a navigation(blue dot) experience. The only problem was if you do a panTo or panBy after rotation, the map will start to move in the wrong direction.

[imeidopf]

Google earth lets us set heading degrees. Rotate being implemented in the core, and better than the existing plugin, would be awesome to load direction-based content some way other than true north. E.g. a golf course has holes in all directions. I would rather look at the map according to my orientation to the existing whole.

[Danielku15]

Support for Vector Tile Layers like MapBox GL including WebGL based rendering.

Looking at all the big Map providers (MapBox GL, Google Maps, Bing Maps etc.) this is the biggest eye catcher nowadays. Vector Tiles offer a lot in flexibility in the rendering of the map elements. Also it offers a much more dynamic display of elements like street labels (rotation, font size etc.). To provide such a professional and modern UX like the commercial players, this likely would imply a new WebGL based rendering backend.

I'd love to see this within the leaflet core like raster tile layers.

This would then also potentially be the foundation for future advanced features like map rotation, 3D Tilt, 3D object display (buildings) etc. Potentially these things could/would come through plugins once the rendering core is there.

I was very impressed with what MapBox GL provides, but it also comes with quite a bit of vendor lock. Seeing a bit more feature parity to it in Leaflet would make me 🤩

[mourner]

Not going to happen (saying this as someone who worked on Mapbox GL JS for 8 years, as well as creating Leaflet). Implementing good vector rendering engine is one of the most difficult things in engineering, requiring years of work by top engineers and millions in investments. For a nice modern library that renders vector tiles and works with Leaflet, I'd suggest checking out https://protomaps.com/

[IvanSanchez]

Vector tiles support is there - in the form of Leaflet.VectorGrid. Do not confuse "support for vector tiles" with "support for complex WebGL symbolization".

I've been doing stuff in the WebGL field since, what, 2015?, and can attest that it's stupidly hard. Only now I'm completing some work on https://gitlab.com/IvanSanchez/gleo , which may be adapted to be a Leaflet WebGL renderer. In the future. If things go according to plan. And, of course, no promises.

That's the main reason why I would like to see this feature request of mine about "Extendable full-map-container DOM elements" done for v3.

But a built-in complex webgl rendering engine as a core feature of Leaflet? Nope. That engine can easily take double the current amount of code Leaflet has.

[Danielku15]

Unfortunate to hear 😢. For me this is the future of web mapping where as raster tiles are rather a relic. We already moved to Canvas rendering due to the poor performance with DOM based rendering (we display quite some markers on our maps). As you pointed out nicely, it is a tough challenge which needs high level expertise in multiple domains.

We might need to consider alternative libraries if Leaflet will not invest in this area. Doing a very basic competitor analysis shows that most other libraries bet on the horse of WebGL rendering (for 3D display and hardware acceleration purposes) and Vector Layers and Leaflet tends to lack behind there. I think almost all libraries nowadays have the basics like Raster Tiles, Custom Markers, WMS, Canvas 2D Rendering, GeoJSON, Custom Shapes, Attributions, Controls, Mobile support, extension APIs,... Of course every library with its strengths in some way (performance, lightweight, easy to use,..) but all providing a similar feature set.

But I also have to admit that we maybe have rather complex scenarios which might also go beyond the primary focus of leaflet being lightweight and easy to use. Those constraints might not be so much of relevance for us.

My reference list:

• Leaflet (Free, Open Source)
• Open Layers (Free, Open Source)
• MapBox GL JS (Free, Open Source, Affiliated with MapBox)
• Google Maps (Commercial, Closed Source, Affiliated with Google)
• Bing Maps (Commercial, Closed Source, Affiliated with Microsoft)
• Here Maps (Commercial, Closed Source, Affiliated with Here)
• Apple Maps (Commercial, Closed Source, Affiliated with Apple)

[SuperPat45]

I use leaflet with some plugins in combination with https://github.com/MapLibre/maplibre-gl-js (the fork of Mapbox GL JS v1.x) as a vector layer.
It works fine, except the JavaScript needed of the 2 API is very huge for small mobile connections.
Having leaflet v3 able to natively handle style.json vector layer will be awesome.
And it would be even better if he could rotate and tilt the map.

[iamtekson]

I found this interesting research. In this research, they compare the performance of three different popular open-source libraries, i.e. leafletjs, OpenLayers and maplibre. The result of this paper was quite surprising to me. The leaflet has the worst performance. Mainly they tried to load the vector tiles using the vectorGrid plugin. I have also tried to check the performance of vector tiles in different mapping APIs and found similar results.

I think v2.0 should address this issue properly and load the vector tile layer in a faster way. Looking forward to seeing this feature in the v2.x.x.

The summary of the research that I mentioned above is here:

[Malvoz]

SVGs for icons: #8158 (comment).

[fox91]

Move from CSS to SCSS/SASS not with the intent of reducing the size of the generated CSS but to give plugins the ability to use the same style (colors, sizes, etc.) as the base components (#5832).

[millette]

Or simply https://developer.mozilla.org/en-US/docs/Web/CSS/var with https://postcss.org/ (like babel for css).

[jonkoops]

I think it's time we created a branch for v3 where we can accumulate breaking changes without influencing the day to day activity on main. This way we can keep landing fixes and other changes whilst having a longer lived branch for non-backwards compatible changes we want to get in.

WDYT @Malvoz @mourner @Falke-Design?

[jonkoops]

Just FYI I can volunteer to keep the v3 branch in-sync with main. I'd rebase it every other week or so. We should naturally try to keep any changes besides breaking ones in the main branch.

[SuperPat45]

A globe view mode like the Google Maps one or Web GL Earth https://examples.webglearth.com/

[SuperPat45]

Use "window.devicePixelRatio" and remove L.Browser.Retina: #8188

[SuperPat45]

Prevent control to cover other controls: #7944 #4644
Maybe by using CSS grid layout?

[Malvoz]

Ref: #7930 (comment)

[richardeschloss]

Hi, I really like the leaflet plugins but it seems like several depend on leaflet "L" being defined globally. For example, my favorite plugin https://github.com/MazeMap/Leaflet.TileLayer.PouchDBCached asks the user to add script tags before loading the plugin.

Would the team be open to supporting something like L.use(plugin, options) so that only a scoped instance of leaflet uses the plugins it defines? For example:

import { L } from 'leaflet'
import TileLayerCache from 'leaflet.tileLayer.pouchDBCached'
L.use(TileLayerCache, { useCache: true })

[jonkoops]

I don't know if we want to implement such an API. We are getting rid of the globals by default in Leaflet 2 (with an opt-in to get them back), at that point we will consider it deprecated and plugins will need to move away from it.

[richardeschloss]

Great! I'm looking forward to Leaflet 2

[iamtekson]

Map idle event similar to Mapbox idle event.