Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Path to customFetch cannot be resolved when building and running a Mesh project #5840

Closed
4 tasks done
cweckesser opened this issue Aug 16, 2023 · 0 comments · Fixed by #5841
Closed
4 tasks done

Path to customFetch cannot be resolved when building and running a Mesh project #5840

cweckesser opened this issue Aug 16, 2023 · 0 comments · Fixed by #5841

Comments

@cweckesser
Copy link
Contributor

cweckesser commented Aug 16, 2023

Issue workflow progress

Progress of the issue based on the
Contributor Workflow

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant