You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Make sure to fork this template and run yarn generate in the terminal.
Please make sure Mesh package versions under package.json matches yours.
2. A failing test has been provided
3. A local solution has been provided
4. A pull request is pending review
Describe the bug
A GraphQL Mesh project that defines a custom fetch can only successfully resolve it when the project is executed using the mesh dev command. If the project is first built (mesh build) and then executed (mesh start), then the file containing the custom fetch function, specified via the customFetch configuration property, will fail to be resolved.
This is because the file .mesh/index.ts generated by the build command will include an incorrect path to the file containing custom fetch function.
To Reproduce Steps to reproduce the behavior:
Detailed instructions on how to reproduce this issue can be found here.
For an already-working example that reproduces this issue, consider the following code sandbox.
Expected behavior
The custom fetch property defined in the Mesh Config file should be correctly generated when running the mesh build command.
Environment:
OS: macOS
@graphql-mesh/cli: "^0.82.35"
NodeJS: 16
Additional context
This issue was already reported here. In this case, a solution is being proposed based on the comment from @saimon-moore.
Cause of the issue
When a Mesh project is built, a .mesh directory is created in the same path where the .meshrc.yml file is found. E.g.:
<PATH_TO_MY_MESH_PROJECT>/graphql/.meshrc.yml
<PATH_TO_MY_MESH_PROJECT>/graphql/.mesh # File created by the `mesh build` command
The .mesh directory will contain a schemas folder (containing the definitions for all the schemas listed in the sources section of the .meshrc.yml file) and a index.ts file.
If the Mesh project requires a custom fetch function, it can be implemented in a JS/TS file, and then that file can be specified in the .meshrc.yml configuration file via the customFetch property. Afterwards, when the project is built, the above-mentioned .mesh/index.ts file will contain an import statement with the path to the file implementing the custom fetch.
The issue occurs when the path to the custom fetch is specified as a relative path, because that path is not adjusted properly when included in the index.ts file. This is, the path specified in the .meshrc.yml file cannot be used verbatim in the index.ts file, due to the latter being located in a different folder:
<PATH_TO_MY_MESH_PROJECT>/graphql/.meshrc.yml
<PATH_TO_MY_MESH_PROJECT>/graphql/.mesh/index.ts # Located in a sub-folder from the .meshrc.yml file (i.e. on a "1st level" sub-folder)
The path needs, therefore, to be adjusted by navigating "one level up", this is, by prepending ../ to the relative path of the custom fetch file.
In the current implementation that generates the import statement that loads custom fetch file, it can be observed that relative paths are not being adjusted. Here, the resolveCustomFetch function loads the custom fetch by invoking the getPackage function.
On the other hand, in the implementation that generates the code that dynamically loads envelop plugins the relative paths are adjusted accordingly.
The text was updated successfully, but these errors were encountered:
Issue workflow progress
Progress of the issue based on the
Contributor Workflow
Github,
Stackblitz
or
CodeSandbox
Describe the bug
A GraphQL Mesh project that defines a custom fetch can only successfully resolve it when the project is executed using the
mesh dev
command. If the project is first built (mesh build
) and then executed (mesh start
), then the file containing the custom fetch function, specified via thecustomFetch
configuration property, will fail to be resolved.This is because the file
.mesh/index.ts
generated by the build command will include an incorrect path to the file containing custom fetch function.To Reproduce Steps to reproduce the behavior:
Detailed instructions on how to reproduce this issue can be found here.
For an already-working example that reproduces this issue, consider the following code sandbox.
Expected behavior
The custom fetch property defined in the Mesh Config file should be correctly generated when running the
mesh build
command.Environment:
@graphql-mesh/cli
: "^0.82.35"Additional context
This issue was already reported here. In this case, a solution is being proposed based on the comment from @saimon-moore.
Cause of the issue
When a Mesh project is built, a
.mesh
directory is created in the same path where the.meshrc.yml
file is found. E.g.:The
.mesh
directory will contain aschemas
folder (containing the definitions for all the schemas listed in thesources
section of the.meshrc.yml
file) and aindex.ts
file.If the Mesh project requires a custom fetch function, it can be implemented in a JS/TS file, and then that file can be specified in the
.meshrc.yml
configuration file via thecustomFetch
property. Afterwards, when the project is built, the above-mentioned.mesh/index.ts
file will contain animport
statement with the path to the file implementing the custom fetch.The issue occurs when the path to the custom fetch is specified as a relative path, because that path is not adjusted properly when included in the
index.ts
file. This is, the path specified in the.meshrc.yml
file cannot be used verbatim in theindex.ts
file, due to the latter being located in a different folder:The path needs, therefore, to be adjusted by navigating "one level up", this is, by prepending
../
to the relative path of the custom fetch file.In the current implementation that generates the
import
statement that loads custom fetch file, it can be observed that relative paths are not being adjusted. Here, theresolveCustomFetch
function loads the custom fetch by invoking thegetPackage
function.On the other hand, in the implementation that generates the code that dynamically loads envelop plugins the relative paths are adjusted accordingly.
The text was updated successfully, but these errors were encountered: