feat: improved navigation for codegen

[jedevc]

This is kind of a bundle of various different patches all to enable "better multi-module navigation". With the incoming work in #8355, we're gonna have even more modules than we currently do today (and we already have a few). Working on a multi-module project is quite difficult, and it's challenging to navigate between functions defined in different modules.

The end goal is to produce something like this (for a module dep that contains a ContainerEcho function), note the dep/src/main.go:31 at the end of the function declaration:

// Returns a container that echoes whatever string argument is provided
func (r *Dep) ContainerEcho(stringArg string, a string, opts ...DepContainerEchoOpts) *Container { // dep (../../dep/src/main.go:31)
	q := r.query.Select("containerEcho")
	for i := len(opts) - 1; i >= 0; i-- {

Most IDEs include support clicking on this link, and navigating to the right place automatically - a future IDE plugin could automatically find this and jump to it.

To do this:

• The SDK typedef API is updated to allow attaching source-maps. These are a record of the filename, the line number, and the column number that a typedef declaration corresponds to in the source. Each SDK analyzes the source code, and outputs these when creating the typedefs during module initialization.
• The engine maps these source-maps from the typedefs onto graphql directives.
• The graphql introspection API is extended to allow querying the directives on a schema
  • There have been multiple proposals (like Expose user-defined meta-information via introspection API in form of directives graphql/graphql-spec#300) to introduce this into the graphql-spec, but there is no official way of doing this. Because we have our own opinionated dagql server though, we can extend this ourselves.
• Each SDK codegen outputs the source-maps as line comments of the form ./path/to/filename:line next to the generated code.

TODO:

• Basic implementation
• Add support for the remaining typedefs: enums, scalars, interfaces, etc.
• Final bits and pieces
  • Parent paths don't work?
    • That path should always be relative from the file it's written to
  • Test drive our CI
• Cleanup 🧹
• Tests 🔨
• More SDK support (maybe a future PR)

[jedevc]

This PR should now be ready to review, it's not 100% feature complete, since it's missing other language support, but IMO it's a good enough starting point to get in.

[jedevc]

Woo, think I've really got the edge cases now. I've also split it out into smaller commits to make it easier to review.

[jedevc]

Note to the reviewer: this is very sad 😢

Ideally, I'd love to be able to define our own "internal" types, and it looked for a while like I could, but python's graphql-core really did not like this: https://github.com/graphql-python/graphql-core/blob/4e83d4201a2be88832f24c5733c0a1b8568c3708/src/graphql/type/validate.py#L181-L196

So, we can just use a single underscore here, and just modify the codegen for the clients to handle this case.

[jedevc]

Note to the reviewer: this change is required because previously we were relying on graphql's typescript library to filter out __ prefixes when creating a schema from an introspection result.

But, with the change to use _ prefixes for "dagger internal" in some places, we need an extra processing step here that we didn't need before.

[sipsma]

🎉

[sipsma]

nit: can this comment be clarified more? The one you have later of // path from the module root to the context was helpful and parsable by my brain 😄