discussion: keep mapbox supports or not

smellman commented 1 year ago

Is your feature request related to a problem? Please describe. @mapbox/mapbox-gl-style-spec does not provide any @types, this means we don't develop as ESM module. But open package force to move ESM module now. If we continue development with @mapbox/mapbox-gl-style-spec, it will be heavy task. I want to drop support mapbox.

How do you think?

JinIgarashi commented 1 year ago

Recent major release of maplibre v3 stop supporting Mapbox style compatibility. If this library need to support Mapbox v2, it requires the latest version of mapbox-gl-style-spec.

However, Mapbox v1 still might be able to be supported by maplibre-gl-style-spec.

v13.17.0 of maplibre-gl-style-spec is the last version support Mapbox v1. https://github.com/maplibre/maplibre-style-spec/blob/main/CHANGELOG.md#13170

If we can use different version of maplibre style spec library for Maplibre v1 and v3, supporting both Mapbox v1, Maplibre v1 and Maplibre v3 are possible, I think.

We may need a script to ask user which map library is used in charites, then initialize style-spec version according to their preferences.

maybe command to initialize a project can be as follows.

npm create charites@latest {folder path}

Which map library do you use?
[ ] Maplibre v3 -> use maplibre-style-spec v19.2.1
[ ] Maplibre v1 -> use maplibre-style-spec v13.17.0
[ ] Mapbox v1 -> use maplibre-style-spec v13.17.0

script create package.json with their preferred library version and generate template HTML and CSS which are under providers folder currently.

hfu commented 1 year ago

Thank you for raising the issue and discussion! It looks to me:

It would be good to support the choice.
However choices should not be a blocker. It would be OK to use not implemented yet if necessary.
Sensible default is important.

keichan34 commented 1 year ago

We mainly use Charites to develop styles for Maplibre, but we do have some Mapbox v2 styles, so at the least I want to keep the preview functionality for mapbox. However, if style validation is where the main problem is, I'm not against removing it.

hfu commented 1 year ago

@keichan34 Good point!

We need to make clear whether we are talking about preview function or about style.json validation, right?

In addition, is there possibility of charities still to generate style.json with old Mapbox style vocabulary from style.yml? Maybe charities can force-generate style.json even if the source yaml is not valid - in case it uses old Mapbox vocabulary.

I thought maybe we can drop Mapbox style validation (support latest Maplibre validation only) but still try to support conversion and preview.

If my thought is not far away from the reality, following is my suggestion about minimum support matrix which I think would be nice.

Maplibre v3 (latest Maplibre GL JS)

[x] validate
[x] convert
[x] preview

Maplibre v1

[ ] validate
[x] convert
[ ] preview

newer Mapbox (latest Mapbox GL JS)

[ ] validate
[x] convert
[x] preview

Mapbox v1

[ ] validate
[x] convert
[ ] preview

Or more simply said:

Preview supports only the latest of each libraries.
Validation can be rigorous / pessimistic.
Conversion should be optimistic - allowing unknown vocabularies, probably when with --force option?

smellman commented 1 year ago

How about this option?

create v1.0.0 release.
charites v1 still supports both maplibre and mapbox. (commonjs)
charites v2 supports maplibre. (ESM module)
backports new feature in v2 to v1.

hfu commented 1 year ago

@smellman Sounds good. I understand that backport is to be done when necessary.

unvt / charites