Absinthe.Adapter does not appear to affect type names

[bbil]

Environment

• Elixir version (elixir -v): 1.16.1
• Absinthe version (mix deps | grep absinthe): 1.7.6
• Client Framework and version (Relay, Apollo, etc): N/A

Expected behavior

Custom adapter can modify the external name for types.

Because of the definition, I would have assumed the to_external_name/2 callback can modify the name of types. But that doesn't appear to be the case.

@typedoc "The lexical role of a name within the document/schema."
@type role_t :: :operation | :field | :argument | :result | :type | :directive
@callback to_external_name(binary | nil, role_t) :: binary | nil

Actual behavior

When using a custom adapter, I am able to generate SDL via an introspection query that modifies field and argument names. But not the names of types.

In the example below, I would have expected the type SomeType to get the prefix applied, i.e. type PrefixSomeType.

Relevant Schema/Middleware Code

Adapter:

defmodule PrefixAdapter do
  use Absinthe.Adapter

  @impl Absinthe.Adapter
  def to_internal_name("Prefix" <> external_name, role) do
    Absinthe.Adapter.LanguageConventions.to_internal_name(external_name, role)
  end

  @impl Absinthe.Adapter
  def to_external_name(internal_name, role) do
    "Prefix" <> Absinthe.Adapter.LanguageConventions.to_external_name(internal_name, role)
  end
end

SDL Generation:

  def generate_schema_idl do
    {:ok, result} = Absinthe.run(introspection_query(), Schema, adapter: PrefixAdapter)

    AbsintheSdl.encode!(result)
  end

And a snippet of what I see in the generated SDL:

type RootQueryType {
  PrefixsomeQuery(PrefixsomeArg: String!): SomeType
}

type SomeType {
  ...
}

[bbil]

If this is expected for how Absinthe.Adapter is supposed to be used then that's fine. But maybe the docs could be clarified for the uses and limitations?

The other option I have been pointed to internally, is to try out https://hexdocs.pm/absinthe/Absinthe.Schema.html#module-custom-schema-manipulation-in-progress. Would that be a better path forward for doing something like this?