Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto upgrade legacy filters #30

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

springmeyer
Copy link
Contributor

This leverages functionality inside the mapbox-gl-style-spec to auto-upgrade legacy filter syntax.

This avoids errors in styles which mix the legacy syntax with the modern syntax.

Will fail until the style-spec version is upgraded, which can happen after mapbox/mapbox-gl-js#8493 is in a release.

@springmeyer springmeyer requested a review from a team as a code owner July 16, 2019 23:39
@springmeyer
Copy link
Contributor Author

springmeyer commented Jul 18, 2019

This is passing on travis except for the coverage build, which I'm working on fixing over at #29

/cc @ian29 @mapsam

@springmeyer
Copy link
Contributor Author

This PR is now rebased against latest master and includes the latest mapbox-gl-style-spec release, which means its ready for further review and testing /cc @ian29 @ericfischer @mapsam

@springmeyer
Copy link
Contributor Author

This PR came up today in conversation with @briandaviddavidson. The main holdup on moving this forward is that we need to build confidence around styleSpec.convertFilter. I don't yet know the answers to these questions:

  • Is styleSpec.convertFilter robust (won't throw odd errors or corrupt output) against all possible styles in the wild?
  • Have there been any recent releases of @mapbox/mapbox-gl-style-spec that we should upgrade to before further testing this?
  • Do we need more unit test coverage in this PR of possible things that can go wrong with running styleSpec.convertFilter against arbitrary input?

Getting the answers to these questions would involve:

  • Building up a large set of sample styles to try running this against
  • Careful canary to further see if any styles in the wild trigger new types of errors
  • Building back any problem test styles into test fixtures
  • Handling any newly discovered errors correctly in the code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant