Autocomplete collection names in getEmDashCollection and getEmDashEntry

[kgni]

The problem

emdash-env.d.ts already extends EmDashCollections, so getEmDashCollection("posts") returns typed data. The name parameter, though, is T extends string:

export async function getEmDashCollection<T extends string, D = InferCollectionData<T>>(
	type: T,
	filter?: CollectionFilter,
)

This means editors don't suggest the registered collection names. A typo such as getEmDashCollection("post") still compiles, and data falls back to Record<string, unknown>. The type error then appears where a field is used, not at the misspelled collection name.

Proposal

Change the constraint so registered names show up as completions while any string is still accepted:

type CollectionName = Extract<keyof EmDashCollections, string> | (string & {});

export async function getEmDashCollection<T extends CollectionName, D = InferCollectionData<T>>(...)
export async function getEmDashEntry<T extends CollectionName, D = InferCollectionData<T>, ...>(...)

CollectionName is always a string, so the internal helpers and InferCollectionData stay as they are. This change adds autocomplete only. Typos still compile.

I have this working on a branch:

• pnpm build, pnpm typecheck and pnpm typecheck:demos pass.
• I tested it against a mock EmDashCollections with posts and pages:
  • Completions inside getEmDashCollection("") list posts and pages.
  • "posts" still resolves to the posts data type.
  • getEmDashEntry("pages", ...) resolves to the pages data type.
  • Unknown literals and plain string variables still compile.

Questions

1. The constraint changes from string to CollectionName but accepts the same values. Typechecks in the repo pass, including core calls that pass a string variable or an explicit <string, T>. Is there code outside the repo, such as tooling or plugins, that could depend on the old constraint?

2. Should the other public helpers that take a collection name accept CollectionName too? These are getTermsForEntries, getAllTermsForEntries, getEntryTerms, getEntriesByTerm, getTranslations and getCommentCount. The only gain would be autocomplete on the collection argument.

3. Would typed taxonomy names be welcome as a follow-up? That means the "tag" in getTerm("tag", slug) and getTermsForEntries(..., "tag"). There's no registry for taxonomies yet, so it would need:

   • A new EmDashTaxonomies interface.
   • generateTypesFile to accept and emit taxonomy definitions.
   • Dev typegen, the typegen route and emdash types to pass them in.
   • Taxonomies included in the schema hash, so adding one regenerates emdash-env.d.ts.