The one place this library asks what a resource looks like.

Every Ash.Resource.Info call in lib/ goes through this module. That is the whole point of it: issue #23 replaces live introspection with the precomputed Ash.Info.Manifest upstream ash_typescript adopted, and a migration spread across 64 call sites in nine modules is not reviewable. One reader makes each later stage a small diff.

Two sources, one contract

Reads take the config map the pipeline and codegen already thread, and look for an optional :manifest key — the same shape :load_restrictions and :is_interop_resource? use.

Omitting the key preserves current behaviour exactly. That is the compatibility guarantee of this stage and the reason it is reversible: no caller in this repo passes :manifest yet, so every read is still live. test/ash_introspection/resource_info_test.exs proves it against Ash.Resource.Info directly rather than asserting it.

resource?/1 is two questions, not one

Ash.Resource.Info.resource?/1 answers a fact about a module. Ash.Info.Manifest.has_resource?/2 answers a fact about the declared API surface. They are not the same question, and 18 of the 64 sites ask it, so this module refuses to guess which one a caller meant:

• runtime_resource?/2 — manifest first, live Ash.Resource.Info when the module is absent from it. For the request path, where the argument can be a runtime value.__struct__ that Ash handed back. A module nobody declared must still serialize as a resource; answering false would silently drop it into the generic Map.from_struct/1 branch.

• declared_resource?/2 — the manifest is the whole answer when one is present; absence means false. For codegen, where scoping is the point: a resource nobody exposed should not appear in generated output.

Both count embedded resources. Ash.Info.Manifest.Generator splits them out of resources and re-enters them under types with kind: :embedded_resource, so a bare has_resource?/2 would answer false for every embedded resource — a divergence from live introspection that has nothing to do with scoping. The only difference between the two functions is what a missing module means.

Everything else defaults to the fallback reading. A site is given declared_resource?/2 only when it is unambiguously codegen.

What the manifest answers in this stage

Stage 1 installs the seam; it does not finish the migration. A function is backed by the manifest here only where both sources return the identical value:

The rest read live even when a manifest is present, and say so below. The reason is shape, not effort: Ash.Info.Manifest.Field carries a resolved %Ash.Info.Manifest.Type{} where Ash.Resource.Attribute carries an Ash type module plus a constraints keyword list. Translating between them is a real piece of work with its own failure modes, and it is what stage 2's decorator exists for. Half-translating it here would put a second, quieter answer next to the live one.

Shapes the two sources cannot share

Where the native return values differ, this module returns a narrow map with only the keys its call sites read, and both sources build it. relationship/3 is the case: live returns %Ash.Resource.Relationships.HasOne{} and friends, the manifest returns %Ash.Info.Manifest.Relationship{}. Callers here read :destination and :cardinality and nothing else, so that is what comes back. identity_keys/3 is the same narrowing over %Ash.Resource.Identity{} versus the manifest's %{keys: [...]}.

Not :resource_info_module

The :resource_info_module config key names the consumer's generated Info module, used for interop_resource?/1 and get_original_field_name/2. It is unrelated to this module and to :manifest.