Removed submodule maplibre-gl-js

[alexcristici]

I copied from maplibre-gl-js the following folders:

• src/shaders -> shaders
• src/style-spec/reference -> scripts/style-spec-reference
• test/integration -> metrics/integration

And updated the scripts and makefiles accordingly.

Some of the reasons behind the decision:

• We need to have the shaders on our repo in order to pursue with the metal support.
• Native and JS have different source code, so they should have separated render tests.
• JS submodule is outdated, I tried to update to latest version but the structure changed considerably without taking into account Native repo.
• Native and JS could have a shared code location, which should be in a shared place and both repos should be aware of that when making changes, which is not happening in this moment. Only Native is aware of JS in case of changes, but JS doesn't care about Native when do changes.

[wipfli]

The style specification file documents internally which platforms support which properties. If we copy the style specification file into this repository, we will have multiple versions and it might be unclear which style specification file is the source of truth for supported platforms across MapLibre.

@HarelM @birkskyum should we move the documentation of the supported platforms out of the style specification file?

[HarelM]

As a temporary solution, this is OK, but I think the style spec repo should either create a package that this repo can use to get the content of the style spec, or simple get the spec file from the style-spec npm package.
This is why we moved the spec outside...

[louwers]

Very nice @alexcristici .

Could you motivate this change? I know this was discussed privately but for the record it would be good to have the considerations behind PRs public, in this case for removing the maplibre-gl-js submodule.

If we copy the style specification file into this repository

This is temporary until the style spec is published as something we can consume. Ideally we should not have to depend on an npm package in my opinion.

[birkskyum]

What makes it difficult to consume the style spec package currently? It's there a link to a discussion around that anywhere

[louwers]

What makes it difficult to consume the style spec package currently? It's there a link to a discussion around that anywhere

I don't think that has been discussed yet. But I only see (TypeScript) source code releases. https://github.com/maplibre/maplibre-gl-style-spec

[birkskyum]

What makes it difficult to consume the style spec package currently? It's there a link to a discussion around that anywhere

I don't think that has been discussed yet. But I only see (TypeScript) source code releases. https://github.com/maplibre/maplibre-gl-style-spec

If you use the repo as a submodule, sure. There are generated js files in the npm package though

[alexcristici]

Very nice @alexcristici .

Could you motivate this change? I know this was discussed privately but for the record it would be good to have the considerations behind PRs public, in this case for removing the maplibre-gl-js submodule.

I updated the description with some of the reasons of this change.

[HarelM]

Thanks for the info.
Copying stuff here is a good starting point to solve some issues as a patch, but not a long term solution. There's a need to better define where everything will be in the future.
I've tried to get a response about what is used and what is not used in native when changing things in web but it wasn't easy to get this info, and a submidule is far from an optional solution from my point of view as you take a lot more than you need and no one knows what's truly needed and what is not.
I hope we can leverage the newly acquired knowledge to better design how the ecosystem will look going forward.

[louwers]

Thanks for updating the description @alexcristici. Good to know you tried to update. Let us know when this PR is ready for review.

I hope we can leverage the newly acquired knowledge to better design how the ecosystem will look going forward.

Agreed!

[alexcristici]

Ready for review!

[ovivoda]

CI/CD ratified it!

Another meticulous PR. Thanks @alexcristici!