Embed Type definition location into the GQL field somehow so we can look it up later to find where a given type was first defined

[JCMais]

Sorry if this is not clear, or already supported, but the goal here is to support the locateCommand option from Relay's (and GraphQL) LSP:

https://www.npmjs.com/package/graphql-language-service-server

https://x.com/captbaritone/status/1748020699263045659

I need a way to, given a specific Type.field, locate the first time it was defined with pothos.

This would allow Go To Definition to jump to the TS source code itself, instead of the GQL schema.

[hayes]

PRs welcome.

It looks like this works in grats by having the ast locations on all the types/fields. We could probably use the same locate script if we could get the locations into the schema, but its not trivial.

grats uses the typescript compiler to parse your source files, so it has a good understanding of how your source is structured, with specific annotations that make it easier to figure out where everything comes from.

Pothos works very differently, and can be very dynamic. Using static analysis to find definitions in Pothos would be very challenging. You could potentially use stack traces to track down the original lines that created a type/field, but even that is going to be tricky, because most of the time you will be executing transpiled source, so you'd also need to look at source maps or something to map back to the source locations.

I'd be more than happy to accepts a PR that implements something like this, but I don't think its likely I'll have the time to prioritize this anytime soon without a more clear path forward

[JCMais]

Thanks @hayes!

Would you accept a PR that does a simple stack trace-based mapping, by adding that information as a private property of the pothos field?

Supporting source path mapping for transpiled sources would indeed increase the complexity of this, but I wonder if for a v0 of this, not having this support is okay. I bet most people use tools like tsx or ts-node to run the TS source directly, instead of running from the compiled source.

[hayes]

I think if we can handle this in a plugin, then starting with a basic stack trace approach makes sense, and it doesn't need to be perfect right away.

I don't think a plugin can work using just the existing plugin hooks. I think it would need to wrap various builder methods. Figuring out the minimal set of methods to wrap might take some work, but I imagine the methods that create core types (eg builder.objectType, maybe ObjectRef.imolement) and the RootFieldBuilder.field/InputFieldBuilder.field methods would be a pretty good place to start.

Happy to accept a PR that adds a plugin like this to the repo if it works reasonably well