Add @map and @mapTo

[martinbonnin]

Supersedes #6352
See #6332
Spec PR apollographql/specs#58

Add @map and @mapTo directives:

extend schema @link(url: "https://specs.apollo.dev/kotlin_labs/v0.5/", import: ["@map", "@mapTo"])

# Maps to an existing class
extend scalar Date @map(to: "kotlinx.datetime.Instant", with: "com.apollographql.adapters.InstantAdapter")

# Maps to a built-in class (possibly generating an inline class)
extend scalar Length @mapTo(builtIn: Long)

I'm not 100% sold on the names yet, feedbacks welcome.

Under the hood, it moves all the scalar configuration to the schema so we don't have to carry around a ScalarInfo struct. The target & adapter information is present directly in the IR.

Moving forward, I'd love to move most of the compiler configuration to extra.graphqls. That would make maintaining a maven/bazel plugin a lot simpler.

[svc-apollo-docs]

✅ Docs preview has no changes

The preview was not built because there were no changes.

Build ID: e6b078b0dafd328e667e29b9

[BoD]

🎉🎉🎉

Re: naming, the only alternative I can think of is @mapBuiltin(to: instead of @mapTo(builtIn: which would be a bit more symmetrical to @map(to: - but no strong preference.

I also wonder if type / adapter would slightly be less potentially confusing than to/ with , but again not sure and either sound good to me.

[martinbonnin]

@mapBuiltin(to:

This reads aloud as "map built-in to Foo" which can be a bit confusing. We're not mapping a built-in, we are mapping TO a built-in

type / adapter would slightly be less potentially confusing than to/ with

I think if we go that road we would want a noun for the directive name:

extend scalar Timestamp @mapping(type: "kotlinx.datetime.Instant", adapter: "com.apollographql.adapters.InstantAdapter")

But the pattern of using verbs is relatively established now (@catch(to:), @provides(fields:), @override(from:), etc...).

[BoD]

But the pattern of using verbs is relatively established now

Very true, also @skip and @defer.

All good then 👍