Parse with linecol offset

[trevor-scheer]

Hello! GraphQL documents are very commonly extracted from other source code, most notably (but not limited to) TS/JS for web client projects.

In order to provide accurate diagnostic locations, it would be a nice addition to be able to specify an initial linecol offset when parsing a document. Currently this can be accomplished in userland by padding the source with newlines and spaces before parsing, and I suspect the internal implementation would look similar.

Would you be open to a PR that introduces this functionality? Thanks for considering!

[duckki]

Nice to talk to you, @trevor-scheer . Are you thinking something like sourcemap?
The utility will be for correct hint/error locations, I think.

[goto-bus-stop]

Yeah, just a starting line/col offset may not be enough since GraphQL documents extracted from other source code (JS, but also strings inside @key(fields:) arguments in federation for example) can contain escape sequences and the like that make the GraphQL source text not line up with the original source text anymore. There's also the inverse problem with strings extracted from GraphQL documents (like the selection syntax for Apollo Connectors). Some sourcemap-type approach supported in both directions would be I think the most robust solution.

[trevor-scheer]

Nice to hear from you both! Yes, the idea is to have accurate error locations in source code that isn't necessarily GraphQL, though preferably agnostic to which language the GraphQL source is written in.

@goto-bus-stop I have the general understanding of sourcemaps but haven't needed to understand impl or details until now, so bear with me please! To clarify, we'd be concerned with cases like these where what's written in source doesn't translate 1:1 to its GraphQL equivalent.

In JS/TS, when using tagged templates and the source contains backticks, i.e.

const schema = gql`
  # escaped code fences like this \`Query\`
  type Query { ... }
`;

Or when using string literals, i.e.

const schema = gql("extend type Product @key(fields: \"sku\") { ... }");

I'm guessing at what to do with this information but understand how this would affect the offsets. Would a solution need to have awareness of which characters to expect escapes for (specifically, backtick and double quote in our examples...others?) and be able to correct for those offsets? Is this something that would be interesting for these crates to support or out of scope?