graphiql-rails v1.5 doesn't work in production
As seen in https://gitlab.com/gitlab-org/release/tasks/issues/962#note_215312407, graphiql loads via
/-/graphiql-explorer in development mode but fails in production with an ugly error:
Error: Cannot use e "__Schema" from another module or realm. Ensure that there is only one instance of "graphql" in the node_modules directory. If different versions of "graphql" are the dependencies of other relied on modules, use "resolutions" to ensure only one version is installed. https://yarnpkg.com/en/docs/selective-version-resolutions Duplicate "graphql" modules cannot be used at the same time since different versions may have different capabilities and behavior. The data from one version used in the function from another could produce confusing and spurious results.
This is also reported upstream here: https://github.com/rmosolgo/graphiql-rails/issues/58
So, as far as I can see the problem is that GraphQLScalarType and GraphQLObjectType constructors both get e as a shortcut during the minifying. And when graphql-js tries to compare them — condition is true and it throws an error.
Disabling name mangling in
mangle: false sounds like a possible workaround, but this may bloat the size of our .JS files.
When webpack compiles our frontend assets, it replaces all instances of process.env.NODE_ENV with "production" and then does some simple resolution to remove dead code in cases where we now have if (process.env.NODE_ENV === "development") replaced with if ("production" === "development")
As you can see in https://gl-staging.freetls.fastly.net/assets/graphiql/rails/application-8b65be01720907edb13a43007ff3727138955d2d22c20412389bd9a8f29fc4f9.js,
"production"!==n.env.NODE_ENV is still present, which suggests that this isn't being done. I suspect this is being bypassed because graphiql-rails may be vendoring its own copy of graphql-js and bypassing the normal Webpack flow.
I think we may want to consider:
- Pulling in only parts of graphiql-rails that deal with the Rails endpoints.