ReadonlyidHuman-readable identity, used to build resolution-failure messages.
OptionaldescribeWhere this root would look — for diagnostics only. Defaults to <id>/<kind>/<pkg>/<relPath>.
OptionalhasWhether this root holds relPath under <kind>/<pkg>/ — or, with no relPath, whether it
holds anything for that package at all.
Tri-state, and the middle matters: false is AUTHORITATIVE absence (backed by the root-level
ResourceRootIndex), so the caller skips the read entirely — that is what makes a miss
impossible by construction. null means this root cannot say (it has no generated listing) and
the caller must probe read as it always did. Roots with no listing simply omit this.
Must not throw: an unreachable or unparseable listing is null, never an error — the listing is
discovery, and absent discovery has a correct fallback (probing) where a broken FILE does not.
OptionalrelPath: stringOptionallistPaths under <kind>/<pkg>/, relative to it, or null when unknown.
Optional on purpose: a served root cannot enumerate a directory over HTTP unless its
root-level contents.json describes it, and its absence here is exactly that fact stated in the
type. Roots that CAN enumerate (a real directory) let a hand-assembled folder work with no build
step.
The bytes at this address, or null when this root does not have them.
One place resources can come from — a directory, a served URL prefix, and (later) a zip, an OPFS handle, an extension host, or an in-memory map in a test.
Roots take the ADDRESS (
kind,pkg,relPath) rather than a joined path, so layout is the root's own business: a directory root resolves<dir>/<kind>/<pkg>/<relPath>, a package self-location root<pkgRoot>/<kind>/<relPath>, a legacy base root<base>/<pkg>/<relPath>. That is what lets the resolver stay a plain ordered search with no per-root special cases.This is NOT a filesystem and should not grow into one — no write, stat, or watch. It is the provider half of a search path (
PATH, classpath,XDG_DATA_DIRS); domain-level merging of what it returns happens above it.