[gql-tag-operations-preset] Generated index.ts should contain \n regardless of whether source contains LF or CRLF

First of all, I would like to thank the creators of gql-tag-operations-preset, it’s a really clever solution to have type safety while avoiding explicit imports.

Describe the bug

TL;DR

Generated index.ts will cause TypeScript compilation to fail when source files contain CRLF (e.g. when using Windows).

Long description

When source file contains LF, generated index.ts will contain \n and TypeScript will compile successfully.

When source file contains CRLF, generated index.ts will contain \r\n and TypeScript will not compile.

When source file contains CRLF, and generated index.ts is manually changed to contain \n, TypeScript will compile successfully.

It seems that generated index.ts should contain \n regardless of whether the source contains LF or CRLF.

To Reproduce

NOTE: I have created a minimal reproduction example. It contains schema, codegen.yml and operations.

Steps to reproduce the problem (using Linux):

1. Modify src/app/app.tsx by replacing LF with CRLF:

$ unix2dos src/app/app.tsx 
unix2dos: converting file src/app/app.tsx to DOS format...

New lines are now CRLF:

$ cat -A src/app/app.tsx
import {gql} from "@my/gql";^M$
import {useQuery} from "@apollo/client";^M$
import React from "react";^M$
^M$
const PET_LIST = gql(`^M$
  query Get_Pet_List {^M$
    petList {^M$
      id^M$
      identificationNumber^M$
    }^M$
  }^M$
`);^M$
^M$
export const MyComponent = () => {^M$
  const {data} = useQuery(PET_LIST);^M$
^M$
  return <>{data?.petList?.[0]?.id}</>;^M$
};^M$

2. Run graphql-codegen by executing npm run generate:

$ npm run generate

> crlf-bug@1.0.0 generate
> graphql-codegen

(node:9963) ExperimentalWarning: stream/web is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
  ✔ Parse configuration
  ✔ Generate outputs

The generated index.ts file will now contain \r\n:

$ cat src/gql/index.ts
/* eslint-disable */
import * as graphql from './graphql';
import { TypedDocumentNode as DocumentNode } from '@graphql-typed-document-node/core';

const documents = {
    "\r\n  query Get_Pet_List {\r\n    petList {\r\n      id\r\n      identificationNumber\r\n    }\r\n  }\r\n": graphql.Get_Pet_ListDocument,
};

. . .

3. Running tsc will now result in a compilation error:

$ tsc
src/app/app.tsx:15:27 - error TS2345: Argument of type 'unknown' is not assignable to parameter of type 'DocumentNode | TypedDocumentNode<any, Record<string, any>>'.
  Type 'unknown' is not assignable to type 'TypedDocumentNode<any, Record<string, any>>'.

15   const {data} = useQuery(PET_LIST);
                             ~~~~~~~~


Found 1 error.

4. Now, if you go to generated index.ts and manually change all \r\n to \n and run tsc again - it will compile.

Environment

• “@graphql-codegen/cli”: “^2.3.1”,
• “@graphql-codegen/gql-tag-operations-preset”: “^1.1.7”,
• “@graphql-codegen/typescript”: “^2.2.2”,
• NodeJS: 16.13.1

Additional info

This ticket suggests configuring .gitattributes to force using LF instead of CRLF on Windows. However, in my opinion it is not reasonable to ask users to change their CRLF strategy in order to work around this, it seems too invasive. Also, unless I’m missing something, it won’t seem to help with source files created on Windows machine.

[vyacheslav-pushkin]

It’s seems that TypeScript does not differentiate between CRLF and LF - both become \n.

// This template literal contains CRLF as line breaks
type CRLF = `one
two
`;

// This template literal contains LF as line breaks
type LF = `one
two
`;

const test1: CRLF = 'one\r\ntwo\n'; // TS2322: Type '"one\r\ntwo\n"' is not assignable to type '"one\ntwo\n"'.
const test2: LF = 'one\r\ntwo\n'; // TS2322: Type '"one\r\ntwo\n"' is not assignable to type '"one\ntwo\n"'.
const test3: CRLF = 'one\ntwo\n'; // compilation passes
const test4: LF = 'one\ntwo\n'; // compilation passes

I’ll work on a PR.

[jmarbutt]

I am having a similar issue, is this happening again?