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

Stoplight dependencies don't support IE or Edge #165

Closed
JamesMessinger opened this issue Apr 20, 2020 · 2 comments · Fixed by #166
Closed

Stoplight dependencies don't support IE or Edge #165

JamesMessinger opened this issue Apr 20, 2020 · 2 comments · Fixed by #166

Comments

@JamesMessinger
Copy link
Member

@P0lip and @philsturgeon - I merged PR #153. All tests pass in Node.js, as well on Chrome, Firefox, and Safari. But they fail in IE and Edge due to the new dependencies that were added (@stoplight/json and @stoplight/yaml). Both of these dependencies use modern ES6+ syntax like rest/spread operators, object destructuring, etc. which is not supported in IE or Edge.

I see a few possible solutions to this problem:

Option 1: Remove unsupported syntax
Stoplight could update its libraries to only use syntax that is supported on IE and Edge. This requires code changes, but no changes are needed to any tooling or build steps.

Option 2: Transpile unsupported syntax to supported syntax
Stoplight could add a transpilation step (e.g. Babel, TypeScript) that converts the unsupported syntax to supported equivalents. This requires no code changes and allows Stoplight developers to continue using the latest syntax features, but requires changes to the tooling and/or build steps of these libraries.

Option 3: Drop dependencies
JSON Schema $Ref Parser could drop the Stoplight dependencies and revert to the previous built-in JSON/YAML parsing logic, which supports IE and Edge. Stoplight could then replace the built-in parsers with their own parsers in Stoplight projects.

@P0lip and @philsturgeon - what are your thoughts on the above options? Is there another option that I haven't considered?

This was referenced Apr 20, 2020
@P0lip
Copy link
Member

P0lip commented Apr 20, 2020

I'd say, we can consider option 3.

The primary reason to have our dependencies is the ability to is more graceful syntax error handling (kind of like fastFail=false for parsing) as well as the ability to produce a range for a particular path.
Now that I think of it, we might not really need it at all? A number of reasons:

  • parsing errors are rather rare for the common use cases of json-schema-ref-parser. They are heavily needed in the context of Stoplight (Studio - where users still design specifications, so the documents are not top-notch yet)
  • we actually do use ranges

Since I broke it, I'm happy to take that task and switch back to the previous parsers if we decide to go with option 3.

I'm afraid option 1 and 2 are not really possible - both json and yaml packages use Proxy internally, which aren't supported in IE.

@philsturgeon
Copy link
Member

3 sounds good, let's get that sorted and I'll review it for ya @JamesMessinger.

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 a pull request may close this issue.

3 participants