Our team is working on adoption of vite + sveltekit.
This is giving a rather large amounts of errors, one of them related to this package, apollo-extensions. What is the responsibility of the Apollo extensions package?
The error we get when building is, something related to ES modules.
> Directory import '/node_modules/graphql/type' is not supported resolving ES modules imported from /.svelte-kit/output/server/app.js
I’m not sure how to assist with the error message you posted or able to understand how it’s Apollo related, but from what I understand, a high level / non-Apollo-answer is that “native” ECMAScript module support — generally, not in an Apollo specific way — does not support resolving directories to modules in the same way, but instead requires that the module being imported has a file extension. e.g., rather than import prop from './directory/, you’d need to do import prop from './directory/index.mjs'.
As for the other error, do you mind sharing the contents of the error you’re receiving about graphql-extensions?
(I’ll note you said apollo-extensions, but you linked to graphql-extensions, so I assume you’re talking about graphql-extensions?)
From a purely informative perspective, graphql-extensions is the version of extensibility that we offered in Apollo Server 1.x and 2.x which is being removed in Apollo Server 3.x in favor of the new, more widely adopted, documented and intended for external-use Plugins API. That means it will still be around for a bit longer, but not for long! That said, it could still be in your way, so if you have any error, that would be useful for debugging.
The context is that we are upgrading out node.js express-apollo app, to sveltekit. In this process, the new builder vite, is using ECMA script modules.
The solution for our issue, was simply to update some code that did the following:
from
import { SchemaDirectiveVisitor } from 'graphql-tools';
to
import { SchemaDirectiveVisitor } from 'apollo-server;
And then everything worked
But it’s always good to know the context of the libraries. Is there anything we can do in our codebase to prepare for graphql-extensions to be removed?
In terms of preparing for the removal of the extensions support, if you are setting anything on the extensions Array of the ApolloServer constructor you should migrate to using plugins (docs linked in my post above).
(For what it’s worth, to facilitate with awareness of the impact, I believe we’ve been offering “deprecation” warnings a server startup time on recent versions of Apollo Server for a while now; I suspect you would be seeing indicators at startup. Also, this was never a public API, so we never really encouraged anyone to use them, therefore they were mostly just used for internal Apollo Server plugins, like our Apollo Studio trace-reporting agent.)
Ok that makes sense. We actually don’t have any extensions array - only using plugins. We are also planning to migrate the studio reporting to the plugins array.