+1 to exploring in the future. A solution that I'd love to see explored more in a future RFC that I think would kill a few birds with one stone:

+ import authorsData from '../authors.json';

const authors = defineCollection({
  type: 'data',
  schema: z.object({
    name: z.string(),
    twitter: z.string().url(),
  }),
+  data: authorsData,
});

Just a thought / not at all blocking this RFC which I agree is smart to treat this as out-of-scope!

What's the use-case for importing like this? It won't work with remote data, I'm surprised at the suggestion.

@matthewp I assume this could allow users to parse data in any format they choose, or even write data in-line with their config. The downside: it would be possible for data to exist outside of content/, which may not feel consistent. Not sure I mind that inconsistency though.

Huge fan of this new getEntry API! It's a clever solution to the ID vs. slug naming complexity you outline below.

You mention getEntries() in the video, but I did a quick search on the page and didn't see that here. Is that included or not? If included, it should be defined here!

Good point! We should add that 👍

Update: added to the references doc. getEntries() is meant for resolving references primarily and shouldn't be recommended for manual use. This is how a manual call would look:

const relatedPosts = await getEntries({ collection: 'blog', slug: 'post-1' }, { collection: 'blog', slug: 'post-2' }, ...);

In fact, we can document "if you want to retrieve multiple entries manually, we suggest getCollection() with a filter."

This should also raise errors ... a mix of content and data in the same collection is detected.

I could see this being a bit of a blocker for the easy upgrade path of a unified src/content directory

If I have a large data collection and only need to upgrade one to use body content for some specific use case, I'd end up having to update every item in the collection to .md files

I can't think of a great example of this at the moment so it may very well be a corner case, feel free to ignore if it isn't a use case worth covering!

Fair enough! There may be a case to allow content inside data collections, since data collections have a subset of content collections' properties. Though it sounds like you're proposing the other way. In that case, we could either mix return types based on the entry's file extension, or allow data collections in content. For the former, properties like render() and body would be added to every collection item and stubbed out with undefined's, which I worry about for usability. For the latter, mixed return types feel risky for usable types when calling getCollection(). We'd need to ship some type guards for appropriate filtering.

My thinking is this:

• Move forward with collection-level types for launch
• Consider allowing content collections in data collections as a fast follow
• Look into the "singleton" discussion here (Singletons in the Content Collections API #449) for one-off .md files as you're describing here. I think there's a use case to allowing one-off entries with a shared schema, though it's something we could tackle separately.

Let me know if that makes sense, or if I'm missing anything!

Given that the RFC is focused on adding support for data collections and a migration path from data entries to content entries isn't a specific goal, I think we can save this question/idea for later!

I honestly don't have a great argument for a solution there. It'll be interesting to see how data collections get used and whether mixing content and data entries in the same collection is even a common enough use case to consider 👍

Yep, another case of "defensively make restrictive, open up if people want it" 👍