chore: upgrades, apollo-client => urql, cleanup

graphql / vscode-graphql

MIGRATED: VSCode GraphQL extension (autocompletion, go-to definition, syntax highlighting)

https://marketplace.visualstudio.com/items?itemName=Prisma.vscode-graphql

MIT License

557 stars 71 forks source link

chore: upgrades, apollo-client => urql, cleanup #338

Closed acao closed 2 years ago

acao commented 2 years ago

upgrade graphql-js, graphql-language-service-server, graphql-config
- solves #334, #320
- upstream improvements in our graphql-language-service-server and the underlying language services
adopt urql in place of apollo client@1
fix some typing issues, use skipLibCheck
upgrade dev dependencies
remove yarn.lock
cleanup

This has been tested locally extensively, however many language server issues will still not be solved by this release

acao commented 2 years ago

oof and of course the peer dependencies errors really don't like that we're on graphql@16 😆

ferm10n commented 2 years ago

What parts of this project actually need the defer stream stuff from graphql@16?

This might be crazy, but maybe we could install it as an alias like npm i graphql16@npm:graphql@^16, alongside graphql@15, satisfying the peer deps

acao commented 2 years ago

We moved to it on the GraphiQL monorepo side for GraphiQL mostly, had to set workspaces all on the same version, and to demonstrate it, and also because there are parts of graphiql that now rely on the defer/stream releases to build partially (but not to function) which should be released within a few minor versions.

the alias may work, good idea. I’m also looking at fixing the Kinds enum/const issue on the lsp side in our own portable way before the breaking change is released. So i can release a patch for that and then we can resolve that fix in this PR and release the extension!

p-szm commented 2 years ago

Out of curiosity, why the switch from apollo to urql?

acao commented 2 years ago

because apollo 1 was too outdated to support, and not compatible with modern graphql. urql is more lightweight and had some more transport spec features than apollo client 3 as well. I am more used to working with urql in my daily work now so it was just a natural choice. we don't pick favorites in the graphql community, haha

apollo client 3 seemed more effort to implement, and if people want an extension that re-creates an apollo client operation, the apollo graphql extension can do that for them!

another option could be even the @graphiql/toolkit createFetcher I created