Introduce monorepo architecture with scoped packages

Consider dividing this package into @graphql/schema, @graphql/execution in a true multipackage monorepo design instead of the loosely divided current “module” setup.

This would allow much easier forking of the executor for customization, without running into the “multiple versions of graphql issue.”

A current alternative that points the way is graphql-executor.

[yaacovCR]

One of the goals of graphql executor is to allow for easily forking the executor, making small changes, and using the result. I think a Babel transform does not as easily allow for that as does a monorepo managed with changesets or lock step versioning. I don’t see a problem with publishing ‘@graphql/js-utils’ to npm, it’s an internal api but it’s not a secret

[yaacovCR]

On much later reflection, @IvanGoncharov , I think your raised a number of important blockers for the above work, especially the internal versioning and intercompatibility issue, the “internal” tools.

I think it would be helpful in the long-term still to move in that direction, but it would certainly require work addressing your above points. I might be able to tackle work on some of those blockers, but not in the short or probably even medium-term.

The overall goal is still excellent imo, i.e. making it easy to plug and play aspects of the graphql pipeline. How to get there is not so clear!