detrohutt / babel-plugin-import-graphql

Enables import syntax for .graphql and .gql files
https://www.npmjs.com/package/babel-plugin-import-graphql
MIT License
314 stars 22 forks source link

fragments absolute paths executed as relative in gql files under react unit test (chai) #43

Open hichriHoussem opened 6 years ago

hichriHoussem commented 6 years ago

So running a chai test on a react component that require a gql file (graphQL query)

#import "src/gql/fragments/activity/activityList.gql"
query getActivities($page: Int, $pageSize: Int) {
  getActivities(page: $page, pageSize: $pageSize) {
  ...activityListInfo
 }
}

the npm script:

"test:unit": "NODE_ENV=test NODE_PATH=./ mocha --require babel-core/register --require ignore-styles --require ./test/index.js --require ./test/dom.js './test/**/*.spec.js'"

as you can see the gql document importing a fragment for the schema the problem is that when i run the test the gql file is trying to take the fragment path as a relative so it look for the file in the wrong location path= 'path_to_gql_schema/path_to_gql_fragment' So I got a no such file or directory error, which can be solved with changing the fragment path to relative.

how can we fix that without changing all gql files fragments path to relative (about a handred) ?

detrohutt commented 6 years ago

My #import implementation doesn't currently respect the NODE_PATH setting, so the path you used above would be relative to the .gql file.

My personal solution would be to use a "Find and replace in project" (I use Atom editor) with a regex pattern to correct the imports by prepending ../ or whatever depending on what level your .gql files are relative to the src folder. Hopefully most of them are At the same depth and you can fix the remaining ones manually. Depending on your folder structure this may not be helpful, but that's the only idea I have. 🙁

clemmy commented 5 years ago

I have a similar issue, but I think this is also an issue with fragments coming from a node_module. Unfortunately, the workaround with manually prepending ../ doesn't always work. Consider the following scenario:

A imports B
A imports C
C imports B

where B is the GQL fragment

Since npm install may dedupe the installation, then B would only exist in the node_module of A, and C should technically resolve B from A's node_modules, but because it's resolved as a relative, it'll be trying to reference a non-existing dependency of C.