global-state expression support in filter and paint properties

[zbigniewmatysek-tomtom]

This PR adds a new map methods: setGlobalStateProperty() and getGlobalState() leveraging the new global-state expression.

Out of the scope: global-expression in layout properties (setGlobalStateProperty() will have no effect on those).

See the style spec update (needs to be merged first) and related issues:
maplibre/maplibre-style-spec#886
#4964

See example:

• test/examples/filter-symbols-using-global-state.html

Launch Checklist

• 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.
• Include before/after visuals or gifs if this PR includes visual changes.
• Write tests for all new functionality.
• Document any changes to public APIs.
• Post benchmark scores.
• Add an entry to CHANGELOG.md under the ## main section.

[zbigniewmatysek-tomtom]

@HarelM feel free to kill me afterwards - I missed one type in the spec: maplibre/maplibre-style-spec#1130 😅

Codecov was failing because fork main was out of sync with base, I will try to keep it in sync now.

[HarelM]

@HarelM feel free to kill me afterwards - I missed one type in the spec: maplibre/maplibre-style-spec#1130 😅

If I'll kill you, it will be hard to push this feature forward 😛

[HarelM]

Doesn't look like codecov approved the merge from main, not sure I know how to solve this... It probably requires some git magic...

[zbigniewmatysek-tomtom]

I propose to solve codecov issue separately, I see that it's failing for most open PRs, also those with passed CI.
There are a lot of old issues reported about wrong head commit, missing head etc. Maybe it's worth trying CLI and https://github.com/codecov/codecov-cli#pr-base-picking

https://app.codecov.io/gh/maplibre/maplibre-gl-js/pulls?prStates%5B0%5D=OPEN

Apart from that, everything else is passing. Spec release is not strictly necessary, I've added @ts-ignore in one test, where type TS was complaining about missing global-state type.
After merging this PR, I need to create another PR to the spec to add ✅ in the global-state docs, so you could as well do the spec release afterwards fixing both things at the same time.

[HarelM]

Most PRs have code coverage, checkout the closed ones.
Can you maybe try opening a different PR, maybe from a different branch (with the same content) to see if we can get the code coverage report? It's important for me to make sure new code has tests covering it.
You might be able to run the coverage locally and see that the new lines are covered, but this might harder than trying a new branch...

If there will be a need to later on remove the @ts-ignore from the test, I prefer to release a new version of the style spec, maybe one that solves the globalstaterefs optional parameter as can be seen here: #5898

[HarelM]

Also there are still two open comments to resolve before this can be merged:

• global-state expression support in filter and paint properties #5613 (comment)
• global-state expression support in filter and paint properties #5613 (comment)

[zbigniewmatysek-tomtom]

I created new PR with squashed content of this one:
#5903

At least patch report was generated: https://app.codecov.io/gh/maplibre/maplibre-gl-js/commit/12ee82f5d0e988986406406fdab2ddc9d7f44fb2

[HarelM]

I've opened a bug and linked it to the above PR, let's see what codecov team will say.

[zbigniewmatysek-tomtom]

@HarelM I run unit tests locally and compared:

	main	#5613
evaluation_parameters.ts	94.59%	94.87%
style.ts	85.77%	86.31%
properties.ts	82.53%	82.66%
map.ts	87.36%	87.44%
src/style_layer	98.28%	98.46%
src/data	67.32%	67.32%

[HarelM]

Thanks for looking into this!
Is there a way to make sure the newly added code is covered by tests somehow besides the statistics you just sent?

[zbigniewmatysek-tomtom]

Most of the significant code changes are in few files.
Maybe you can run coverage locally and asses if the coverage is at the acceptable level?

[HarelM]

Can you resolve conflicts please? I'll merge this afterwards.

[HarelM]

Ok, one last question: are getLayoutAffectingGlobalStateRefs and _findGlobalStateAffectedSources well covered (>90%)?

[zbigniewmatysek-tomtom]

@HarelM I ensured both methods have 100% coverage: