graphql version used is: [email protected].
shadow-cljs is a build tool for ClojureScript + JS that among other things enables using npm packages directly (via ClojureScript). To achieve this it uses the Closure Compiler extensively instead of the usual babel or webpack.
Closure will rename pretty aggressively and this causes some of the graphql/types/definition classnames to end up having the same constructor.name. The instanceOf check then falsely reports this as a problem and a check that is supposed to fail and return false throws an error instead.
Previous Report (before I figured out the problem)
A user reported a build issue when trying to use the the graphql package where I cannot figure out the cause. No compiler error or so occurs, only a runtime issue.
Cannot use a "__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.
There is definitely only one graphql instance in the code and it isn't even used so it happens during initialization.
I sort of tracked this down to be a Closure Compiler issue which I reported here: https://github.com/google/closure-compiler/issues/2898
I thought I'd raise this here as well. Maybe someone has a clue what might be happening. I have not used the graphql package myself but I'd like to resolve this problem.
All code is available here: https://github.com/thheller/issue-248
The two failing builds are
simple is using source maps. pseudo is simple but without source maps, instead it is pretty printed and using pseudo names (easier to step through the actual code and not what it used to be).
And the working whitespace-only build
https://code.thheller.com/issue-248/whitespace/
Really just hoping someone more familiar with the code has a clue what might be happening. Closure seems to be the cause here not graphql.
I finally identified the issue.
graphql does not expect that a development build might rename things. Therefore the first instanceof check fails correctly but the second check then goes on to compare the constructor names. Since Closure renamed those to something short like a they are identical and the check fails. Just removing the second check fixes all issues.
I'm having this issue with the Serverless Framework which uses Webpack. I actually did what it said to do, we're already using Yarn. However, it had no effect. For now I'm having to set NODE_ENV='production'
This name checking behavior only occurs in non-production environments, since like you're encountering - other build tools can rename source code.
Setting NODE_ENV=production before running a CLJS build or any other kind of minifying/obfuscating build is absolutely the right thing to do
In a CLJS development build I want to use development mode JS dependencies. Forcing production mode kind of defeats the purpose of having a development mode in the first place.
Many packages provide useful extra information in dev mode and I don't want to miss that. You are also attempting to provide useful information but just rely on a broken assumption to do it.
The problem you are trying to warn about cannot happen in shadow-cljs and it is very unfortunate that we are forced to add extra config for graphql (and just graphql, nothing else requires this) just to avoid running into an error generated by a confused graphql check when actually everything is OK and working as intended.
Happening for us too. Webpack mangles constructor names, they cannot be relied on, whatever the value of NODE_ENV is. Any chance to get this reopened?
Most helpful comment
In a CLJS development build I want to use development mode JS dependencies. Forcing
productionmode kind of defeats the purpose of having adevelopmentmode in the first place.Many packages provide useful extra information in dev mode and I don't want to miss that. You are also attempting to provide useful information but just rely on a broken assumption to do it.
The problem you are trying to warn about cannot happen in
shadow-cljsand it is very unfortunate that we are forced to add extra config forgraphql(and justgraphql, nothing else requires this) just to avoid running into an error generated by a confusedgraphqlcheck when actually everything is OK and working as intended.