You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 20, 2024. It is now read-only.
Hey! I saw that helix has some support for running on deno, and was inspired to make one of my projects (GiraphQL) work on deno as well.
GiraphQL is a graphql schema builder that doesn't handle any of the server logic, making it an ideal pairing with helix. I couldn't find much info on how you recommend setting up helix on deno, but after some tinkering got something that works.
A couple issues I ran into:
It looks like something in render-graphiql.ts causes deno's parser to choke and crash the process. I worked around this by just importing the other files directly and using something else to load graphql playground.
the way the graphql library is written makes it impossible to use multiple copies of graphql together. This isn't a huge issue in node because you can use things like yarn resolutions to ensure only one version of graphql exists in you node_modules directory. This can be worked around in deno using import-maps. The down side of this is that every time you update helix you need to dig through the source to find exactly which version (and url) is being used to load graphql, and then update your import-map to match.
I was curious if you had run into any of these issues or had thoughts on best practices to recomend to users of our libraries.
One idea I had that may make sense is to always use the same url/version of graphql (something like https://cdn.skypack.dev/graphql?dts), and strongly encourage users to use import maps that replace this version. By using a non-versioned url, new users will pick up the latest version by default, and user upgrading libraries don't need to worry as much about check the specific versions being imported by the new version.
I put together some docs with an working example of GiraphQL and helix here https://giraphql.com/guide/deno if you're curious.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hey! I saw that helix has some support for running on deno, and was inspired to make one of my projects (GiraphQL) work on deno as well.
GiraphQL is a graphql schema builder that doesn't handle any of the server logic, making it an ideal pairing with helix. I couldn't find much info on how you recommend setting up helix on deno, but after some tinkering got something that works.
A couple issues I ran into:
render-graphiql.ts
causes deno's parser to choke and crash the process. I worked around this by just importing the other files directly and using something else to load graphql playground.import-maps
. The down side of this is that every time you update helix you need to dig through the source to find exactly which version (and url) is being used to load graphql, and then update yourimport-map
to match.I was curious if you had run into any of these issues or had thoughts on best practices to recomend to users of our libraries.
One idea I had that may make sense is to always use the same url/version of graphql (something like
https://cdn.skypack.dev/graphql?dts
), and strongly encourage users to use import maps that replace this version. By using a non-versioned url, new users will pick up the latest version by default, and user upgrading libraries don't need to worry as much about check the specific versions being imported by the new version.I put together some docs with an working example of GiraphQL and helix here https://giraphql.com/guide/deno if you're curious.
The text was updated successfully, but these errors were encountered: