Use graphql-js's types as a library

[jimthedev]

I know there is a current limitation where two instances of Graphql cannot be in your app, however, I have created http://npm.im/gra which wraps the graphql types to be shorter. The problem is that in a monorepo setup using lerna or something similar, I cannot have one npm package which uses express-graphql and a separate one for the schema which relies upon graphql. Would it be possible to publish the graphql types in their own repo so that they can be relied upon without the restriction or is the coupling pretty tight? It would just be nice to be able to use graphql-js's types as a library.

Thanks!

[stubailo]

I cannot have one npm package which uses express-graphql and a separate one for the schema which relies upon graphql.

I don't see why this would be the case - does a monorepo necessarily restrict the dependencies of the subdirectory? Also, express-graphql and graphql don't overlap at all as far as I know.

[jimthedev]

This is the issue I was reading to find out more about the error I was getting. graphql/graphiql#58

They overlap in some sense: https://github.com/graphql/express-graphql/blob/bdd7a954aff7621bb338d722b44371f7643c2258/src/index.js#L12:L20

I will try to whip up an example repo.

[leebyron]

We've tried to set up the dependencies such that npm will install in a flattened way. Of course, this is notoriously challenging thanks to npm so YMMV.

For example, with express-graphql, this peer-dependency is intentionally extremely loose https://github.com/graphql/express-graphql/blob/master/package.json#L98

[vovacodes]

The peerDependencies approach doesn't work if you use symlinking during development (quite common for the lerna monorepos), npm won't hoist the instance of graphql that is specified as a dependency of a linked package.

@leebyron But still what about the original question, are there reasons we cannot split the graphql package into the "types" and "runtime" parts so that two instances of graphql is not an issue anymore?

[IvanGoncharov]

Problem is that "types" part also use some of "runtime" parts so instead of solving issues it will likely introduce the new ones.
Moreover "runtime" part can't work with a different version of "runtime" part.

IMHO, the multipackage setup works for projects with a loose coupling like core and "plugins", e.g. Babel.

I'm closing this issue since we released a first stable version(14.0.0) and don't have any plans to do global changes like this one.