Open snikch opened 1 year ago
Hmm, this may be caused by presence of import {PluginDefinition} from "apollo-server-core";
in index.d.ts
.
We can probably remove this import and make types for Apollo3 plugin weaker a bit.
Better solution might be to move Apollo3 plugin to separate js
and d.ts
file as apollo4 plugin, but it is a breaking change, so I'd like @confuser to help decide what to do.
@apollo/server
is included in the package.json
so I don't think this is the issue. I created a fork and simply removed the createApolloQueryValidationPlugin
function and it is working successfully, so I believe it's definitely the issue that require('apollo-server-errors')
is not listed as a dependency.
I do know nothing about next.js framework, so it is hard to determine. Is it and your project TypeScript or pure JavaScript?
In this module's package.json
, apollo-server-core
is in devDependency
, and apollo-server-errors
is its transitive dependency. It is intentionally not in dependencies
not to be included in projects not using Apollo3. But devDependencies
from modules are typically not included.
In the index.js
, this require('apollo-server-errors')
is intentionally in the code and not at the beginning, so should be used only if this code is used, but I'm not sure, maybe not. In index.d.ts
it is imported at the beginning, so always.
So I'd expect your project uses TS, and that import in types file is the problem.
Anyway, as I wrote before, for me the best solution should be to extract Apollo 3 plugin (and maybe even Envelop plugin) to separate files. But this is a breaking change, so I'd like to know @confuser opinion first, before I start to implement it.
Agree that the solution would be to have separate plugins!
Workaround:
Create a missing_apollo_types.d.ts
(name does not matter) file in your project with the following content:
declare module 'apollo-server-core' {
interface PluginDefinition {
_: unknown
}
}
@velias I think the best solve which is a larger change is to create a monorepo with a core folder containing the main business logic and then each plugin being its own package. Otherwise it'll mean installing a bunch of dependencies that aren't needed just to cover multiple use cases
Agree, this is indeed the right solution. But it is a bit larger change ;-)
Given that Apollo 3 is not supported anymore it could be possible to simply remove Apollo 3 plugin at all with all its dependencies.
Docs (https://www.apollographql.com/docs/apollo-server/previous-versions) says:
Apollo Server 3 is deprecated and will transition to end-of-life on October 22nd, 2023.
I've opened a PR here to address this. The fix is quite small, simply moving an import around to prevent unnecessary import (and attempted typecheck) on apollo-server-errors
when using the apollo4
import.
When importing this package into a next.js app, I get the following error. I believe because https://github.com/confuser/graphql-constraint-directive/blob/master/index.js#L135 attempts to
require('apollo-server-errors')
which is not a dependency of this package.I'm not really sure what an appropriate resolution here is, short of moving the individual library support to alternative packages.