Update package to support multi features

[HarelM]

Launch Checklist

Fixes #3516
Incorporates the following PR from style-spec repo:

• "geometry-type" to identify Multi- features maplibre-style-spec#519
  Fixes:
• Filter can't be applied to type: MultiPolygon #3516

This basically updates the spec package.

• Confirm your changes do not include backports from Mapbox projects (unless with compliant license) - if you are not sure about this, please ask!
• Briefly describe the changes in this PR.
• Link to related issues.
• Add an entry to CHANGELOG.md under the ## main section.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.85%. Comparing base (0ffa890) to head (b60d3c4).
Report is 251 commits behind head on main.

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4877      +/-   ##
==========================================
+ Coverage   87.77%   87.85%   +0.07%     
==========================================
  Files         265      265              
  Lines       37970    37970              
  Branches     2446     2409      -37     
==========================================
+ Hits        33328    33358      +30     
+ Misses       3568     3551      -17     
+ Partials     1074     1061      -13     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[hyperknot]

This change is breaking backward compatibility. I am getting reports from OpenFreeMap that styles are not displaying correctly. I can try to update the styles urgently, but I want to say this is really not great how such a breaking change was added so quietly.

With the font issues, I saw how backward compatibility was considered a top priority. The project decided to keep a super old, hardcoded font name forever, just to maintain backward compatibility. I agree with that decision, as keeping backward compatibility is super important.

This change, however, is 100x more serious compared to an old font name! This actually breaks maps all around the internet!

Can you possibly revert this in 5.0.1? I mean every single website that soon updates MapLibre will have their maps broken! I don't mean just OpenFreeMap, I mean your entire install base!

NPM says that MapLibre is downloaded 176k times per week, which is almost a million installs per month! Please don't break all those websites, CMS plugins, etc. where MapLibre was set up years ago!

Moreover, with OpenFreeMaps, I've made sure that every style published was linted with gl-style-migrate, so these were officially linted styles which are now broken. I understand that the lint tool has also been updated, but the point is that even if your users used the official lint tool a few months ago, their maps are now broken!

Please consider reverting this breaking change in 5.0.1, before millions of MapLibre maps break across the internet.

[HarelM]

This was the community decision.

[wipfli]

If I remember correctly, the behavior of the ["geometry-type"] expression was changed to align it with what the specification says it does. And the change solved some problems related to that misalignment. So if we were to revert, we would still have the old problems and spec that does not match the implementation.
How would you solve the issues around ["geometry-type"] @hyperknot ?

[hactar]

Please consider reverting this breaking change in 5.0.1, before millions of MapLibre maps break across the internet.

Hmm. Changes that are not backwards compatible always suck, but in order to continue development in an adequate speed, sometimes these must be done. The established way of doing this is increasing the major version number, and warning about this in the documentation/changelog. The old version should still continue to be available for people who can't change immediately (version 4.7.1). All of this was done in this case.

I would hope that the "millions of maps" have their auto-update system set up correctly so that they don't fetch version 5 automatically as is best practice? And if they don't, limiting to a version below version 5 is a single line change people could do to quickly fix their broken map?

[prusswan]

Apparently this causes multi geometries to not display (e.g. protomaps/PMTiles#511). While major version upgrades can be expected to have breaking changes, this may require a more prominent warning elsewhere (I saw #5290, but this came after the v5.0.0 tag so people who check by tags would not have seen it). For developers they will probably end up here one way or another, but new users may go to the website, look up some examples then make a new map using some style they found off the internet, then wonder what actually went wrong. Is there some kind of migration guide on the website? Also, from the specs it is not exactly clear why $type would work for multi geometries. Seeing that it is only mentioned under the Deprecations section, does this mean "special keys" will also go away at some point?

[hyperknot]

About the lack of warnings:

• The official linting tool, gl-style-migrate has shown absolutely nothing in versions 19, 20, 21 or even currently, version 22.
• There have been no console warnings either during the lifecycle of 4.x or even now in 5.x

Basically it's almost impossible to figure out why maps broke, without any depreciation warnings displayed to the user.

[prusswan]

Also, the poll (maplibre/maplibre-style-spec#536 - not exactly the place most people will find) only had 13 responses, so the results are not really meaningful. Majority of users have yet to consider the issue and even understand the actual impact.