Support importing fragments

[kumarharsh]

Transferred from kumarharsh/graphql-for-vscode#22

@majodev said:

Enhancement, see documentation in gql-tag.

@kumarharsh said:

@majodev - from what I read, this is a webpack feature rather than an editor feature. Can you clarify exactly what you mean?

@majodev said:

Sure, this allows to import fragments from other files, however the plugin does not understand the import syntax, which leads to NoUnusedFragments and KnownFragmentNames errors.

See the attached screenshot.

@kumarharsh said:

OK, I understand, thanks for the screenshot too. I'll look into how to do this.

@kumarharsh said:

I think the gql repo will be the best place to handle this.

[jvbianchi]

any news?

[Mayank1791989]

@jvbianchi you can disable validation rules to suppress errors

// .gqlconfig
{
  match: "path/to/files",
  validate: {
    extends: "gql-rules-query",
    rules: {
      KnownFragmentNames: "off",
      NoUnusedFragments: "off"
    }
  }
}

[jvbianchi]

@Mayank1791989 I done it. It solved the errors for me. Thanks

[mgadda]

I'm not sure that suppressing the errors is necessarily the best solution. One might want to know, for instance, about truly unknown or unused fragments, not just fragments from other files.

graphql-language-service provides a good model for how I think it could work. All of the fragments glob'd from query.files.match have their fragments stored in a map of name to parsed fragment. This information is made available as needed for autocompletion, validation, etc of queries that may reference fragments specified in the same file or other files. Essentially, everything that gets glob'd is globally namespaced. No #imports required.

[Mayank1791989]

I'm not sure that suppressing the errors is necessarily the best solution. One might want to know, for instance, about truly unknown or unused fragments, not just fragments from other files.

@mgadda suppressing errors is only a temp solution for above import based graphql files as I dont want to implement #imports which is not part of graphql spec and very specific to javascript language client.

All of the fragments glob'd from query files.

Yes It's already on the roadmap of next version to support relay-modern client and it will be something similar to that.

[ntziolis]

Any update on this?