Add api-supported-mode to spec.validate

[samanpwbb]

The style API has stricter stylesheet validation than Mapbox GL JS. This PR adds a new mode to the validator that will inform the user if their style is fit to be uploaded to the style API. The purpose of this PR is to add transparency to the style API and unify test suites for both validation steps.

Changelog suggestion:

• Add a new validation function that returns the same error responses as the Mapbox Styles API. Use as a CLI tool with gl-style-validate --api-supported-mode. Use in Javascript by importing validateMapboxApiSupported from the @mapbox/mapbox-gl-style-spec package.

Launch Checklist

• briefly describe the changes in this PR
• Finish the code
• write tests for all new functionality
• document any changes to public APIs
• post benchmark scores
• manually test the debug page
• tagged @mapbox/studio and/or @mapbox/maps-design if this PR includes style spec changes
• tagged @mapbox/gl-native if this PR includes shader changes or needs a native port

[asheemmamoowala]

@samanpwbb The approach taken here looks good to me.

[samanpwbb]

Okay, this is ready for review. I opted for creating a validation function that is fully independent of the existing recursive validation function. The existing system highly depends on the style-spec config file, while my new validator is a little more imperative.

I considered writing api-style-supported mode as a new version of spec instead (or rather, as a set of overrides that would be merged into the main spec before tests run). I think this would be cool, but realized that it add quite a few new challenges. For example, I would need to add new pattern-matching validators to the style spec, so I backed out and kept things simple.

I would love a review from @jseppi in addition to a review from the gl team, since this PR significantly impacts upstream work in api-styles.

cc: @mapbox/map-design-team 😄

[samanpwbb]

Oh one more thing: How am I supposed to test the function in style-spec/bin ? Trying to run them directly didn't work :|

[arindam1993]

LGTM
Minor nitpick, also more of a question, any reason to use .forEach instead of for..of?

[samanpwbb]

Minor nitpick, also more of a question, any reason to use .forEach instead of for..of?

Here: https://github.com/mapbox/mapbox-gl-js/pull/8663/files#diff-abf4b5c9003a59059bbce3d73ab97182R65 – I need index to report a nice key for the error, and forEach is a little nicer than tracking an i variable. Since I was using forEach there I stuck with it. I wasn't able to discern from GL's codebase a preferred style for iterating over objects but I'd be happy to switch to for..of if that's more inline with the direction you all are headed in.

[jseppi]

Generally I think this looks really good, @samanpwbb!

A few nits and small questions that I think you can just clean-up or decide not to address.

[asheemmamoowala]

Thank you for adding the tests. They are 💯

[kkaefer]

@samanpwbb could you please draft a note for our changelog?

[samanpwbb]

Here:

• Add a new validation function that returns the same error responses as the Mapbox Styles API. Use as a CLI tool with gl-style-validate --api-supported-mode. Use in Javascript by importing validateMapboxApiSupported from the @mapbox/mapbox-gl-style-spec package.

If that’s too long, just use the first sentence