Using path aliases breaks eslint validation

[Thinkscape]

We're referencing quite a lot of the generated GQL types within our project and end up with quite annoying, and easy to break imports like

const QUERY = gql`
  query Something{} 
` as import('../../../../__generated__/ts-gql/Something').type;

As a solution we attempted using TS path aliases, such that in tsconfig.json we put

{
  "compilerOptions": {
    "paths": {
      "@gql/*": ["../../../../__generated__/ts-gql/*"]
    }
  }
}

and our import becomes:

const QUERY = gql`
  query Something{} 
` as import('@gql/Something').type;

However that is not accepted by the eslint plugin, which will complain with:

 error    You must cast gql tags with the generated type  @ts-gql/ts-gql

I haven't found a workaround yet. tsc is happy with the imports, if I disable the ts-sql eslint plugin then I can build it in Next.js context.

Is there an easy fix or does it require refactoring the plugin?

Cheers,

[Thinkscape]

@jesstelford I'm opening issue for now 🤷

[dror-laguna]

I am getting this error, without the path change :\

[airtonix]

@Thinkscape what do you mean by this?

and easy to break imports like

const QUERY = gql`
  query Something{} 
` as import('../../../../__generated__/ts-gql/Something').type;

because if you're using the eslint plugin and the rules and auto fix in your editor, then you shouldn't need to care what the paths look like or if they're correct.

[Thinkscape]

It fully relies on the eslint plugin doing the heavy lifting, which usually works but sometimes doesn't. It might break when interacting with other plugins, refactoring (i.e. renames or moving stuff around). Sometimes I found the plugin just gets confused and does nothing, or doesn't produce correct results. There wouldn't be need for a plugin if the paths were trivial and discoverable by IDE itself... or just human-rememberable.

[airtonix]

We don't use aliases, and I'm not really fond of them to begin with. So what changes occur as a result of this issue would need to accomodate others who dont want aliases.

I've never had a problem with the plugin not being able to correctly generate the paths.

You'd have to be more specific in detailing the cases where you're referring to:

but sometimes doesn't. It might break when interacting with other plugins, refactoring (i.e. renames or moving stuff around). Sometimes I found the plugin just gets confused and does nothing, or doesn't produce correct results.

Because over the last 2-3 years our team of roughly 10-15 developers never reported this kind of problem.