Bug: Import paths in the generated typescript schema file contains backslashes when codegen is run on Windows 11

[kasper573]

Hello! I've been trying out this project this weekend. Really interesting, nice work!

I noticed that the import paths in the generated typescript schema contains backslashes. Here's what mine look like:

import { count as queryCountResolver } from "./modules\\api-tester";
import { files as folderFilesResolver } from "./modules\\file";
import { dir as queryDirResolver } from "./modules\\file";
import { error as queryErrorResolver } from "./modules\\api-tester";
import { greeting as queryGreetingResolver } from "./modules\\api-tester";
import { increaseCount as mutationIncreaseCountResolver } from "./modules\\api-tester";

I ran into this when I tried to bundle my graphql server using tsup, which then outputs an error due to this path format:

ESM Build start
Error: R] Could not resolve "./modules\\api-tester"

    src/schema.generated.ts:2:44:
      2 │ import { count as queryCountResolver } from "./modules\\api-tester";
        ╵                                             ~~~~~~~~~~~~~~~~~~~~~~~

Error: R] Could not resolve "./modules\\file"

    src/schema.generated.ts:3:45:
      3 │ import { files as folderFilesResolver } from "./modules\\file";
        ╵                                              ~~~~~~~~~~~~~~~~~

ESM Build failed

I'm very curious why grats outputs imports like this!

[captbaritone]

Interesting, I haven't seen this before. May I ask which operating system you are using?

[kasper573]

I am using Windows 11. I've been comparing with the codegen results in my CI (which runs ubuntu) and my CI generates typescript with proper import paths. So it does indeed seem to depend on OS. So could this be considered a bug perhaps?

I have a CI step that asserts that the codegen is up to date, which currently yields false negatives if I submit code that was generated on windows machine:

❌  src/schema.generated.ts out of date. Run codegen and commit changes.
--- A
+++ B
@@ -1,10 +1,10 @@
 // Generated by Grats. Do not edit manually.
-import { count as queryCountResolver } from "./modules\\api-tester";
-import { files as folderFilesResolver } from "./modules\\file";
-import { dir as queryDirResolver } from "./modules\\file";
-import { error as queryErrorResolver } from "./modules\\api-tester";
-import { greeting as queryGreetingResolver } from "./modules\\api-tester";
-import { increaseCount as mutationIncreaseCountResolver } from "./modules\\api-tester";
+import { count as queryCountResolver } from "./modules/api-tester";
+import { files as folderFilesResolver } from "./modules/file";
+import { dir as queryDirResolver } from "./modules/file";
+import { error as queryErrorResolver } from "./modules/api-tester";
+import { greeting as queryGreetingResolver } from "./modules/api-tester";
+import { increaseCount as mutationIncreaseCountResolver } from "./modules/api-tester";
 import { GraphQLSchema, GraphQLObjectType, GraphQLNonNull, GraphQLInt, GraphQLList, GraphQLUnionType, GraphQLID, GraphQLString } from "graphql";
 export function getSchema(): GraphQLSchema {
     const FolderType: GraphQLObjectType = new GraphQLObjectType({
 ELIFECYCLE  Command failed with exit code 1.
 ```

[captbaritone]

Got it. Yeah, this sounds like a bug. I'll try to investigate. We can use this issue to track it.

[captbaritone]

Quick update. Still trying to get a windows environment working where I can look at this. If this is blocking you let me know and I can brainstorm some workarounds.

[kasper573]

I worked around it by adding a simple transformer to esbuild for now 😆: https://github.com/kasper573/yas/blob/de33f485e0ef1c7d512811e57adba9e236c508eb/apps/graphql-server/tsup.config.mjs#L15

So no worries, not blocked!

[captbaritone]

I've landed a change which I think addresses the slash issue. I think we might still be writing files with different line endings on different platforms but I think Git tries to normalize those?

Can you try grats@0.0.0-main-b0fafefe and see if it resolves the issue for you?

[kasper573]

@captbaritone Yes, it seems to work as expected! Yeah I think the line endings might still be a problem theoretically, but you're right that git normalizes them for most users. I don't have a problem with line endings, but some users may use git with a different configuration/workflow so it could still be a problem for some.

[captbaritone]

@kasper573 Thanks for confirming. I've opened #136 to track line endings.