Content typings support roadmap

[Tahul]

As for now, if you want to have proper typings when using queryContent; you should pass an argument to it that extends ParsedContentMeta.

import type { ParsedContent } from '@nuxt/content'

interface MySpecificContentType extends ParsedContent {
	foo: 'bar'
	test: 'test'
}

const { data } = await useAsyncData(
	() => queryContent<MySpecificContentType>({ ...yourQuey })
)

const slug = data.value.slug

const foo = data.value.foo

This is obviously not the final approach we want to provide with @nuxt/content.

The next step for us is to generate types in development based on the actual data from these files.

Until we reach that point, the recommended approach is to use type augmentation, which will be the easiest "change" to replace in your codebase once that type generation feature reaches release.

[seangwright]

This solution no longer works, because useAsyncData types the returned data with a Pick<T, string> due to the { [key: string]: any } of ParsedContentMeta.

See nuxt/nuxt#14440

[GerryWilko]

Hello, this issue is quite old but as it is still referenced from the docs I wondered if it was the right place to discuss a proposed feature to improve the typings on Nuxt content. I love the concept of the types from query content params but in my case I am using dynamic parameters to the content module so it may make this tricky (not impossible though).

What I was wondering was allowing users to lean on validators like zod to provide the type safety and validate the front matter returned with content pages.

I was wondering about adding a hook such as validate((c) => validate(c)) or hook((c) => validate(c)) to allow users to validate the pages returned and/or augment the types in some way.

The resultant hook would combine the returned type with MarkdownParsedContent allowing the following use case.

const pageSchema = z.object({
  navigation: z.object({
    nextBtn: z.string()
  })
})

export default function () {
  return queryContent('some-param').hook((c) => pageSchema.parse(c))
}

This hook would be evaluated just before queryContent is evaluated. This allows chaining of this using the QueryBuilder<T> whilst ensuring that the returned object is typed and validated. Also validation library agnostic so no lockins here.

I would like to add this what do the team think?

This could also be extended to add a parameter before for the hook name. That way in future if there was to be other hook points we could support them?

[GerryWilko]

I was thinking something like this:

It feels a little clunky but not sure I can do this better with the current structure of the queryContent composible. What do the team think of this change?