Allow me to define fields I don't want in the output

[seancdavis]

I often have content in my source that is strictly used for processing. Right now Contentlayer skips that content because they have extra content not defined in the schema.

Consider the following content structure:

---
title: "Post #1"
imageSrc: tools/open-source-project/2022-03-09-open-source-project.png
---

I want to process this image on S3 using some image delivery service, so I do this:

export const Post = defineDocumentType(() => ({
  name: "Post",
  filePathPattern: `posts/**/*.md`,
  fields: {
    title: {
      type: "string",
      required: true,
    },
  },
  computedFields: {
    image: {
      type: "string",
      resolve: (doc) => {
        // process image ...
      },
    },
  },
}));

This doesn't work unless I also define imageSrc as a field. I don't necessarily want to do that, because that's extra data in my output that I'm not going to use in my app (after processing).

I think there are two related ways to approach this. Both may be applicable:

1. Option to ignore fields in the content source. (Note: I think it's fine if this has to be explicitly stated for better/easier validations.)
2. Ability to overwrite an existing field as a computed field. It would also be great to be able to define image in the content source and as a computed field. (This would be a better first step IMO over the previous point, as it would solve for this case.)

---

Somewhat related to #11, depending on the path CL takes with image processing, but there's more here.

[schickling]

You raise some good points - thanks for opening the issue @seancdavis!

Re (1): This is already possible via the onExtraFieldData option:

export default makeSource({
  contentDirPath: 'posts',
  documentTypes: [Post],
  onExtraFieldData: 'ignore',
})

Re (2): That's a great point. Feels like the same underlaying use case as described in #91. Do you agree? If so, we could expand #91 and close this issue?

[seancdavis]

@schickling Yes, thank you! The combination of onExtraFieldData and #91 should do the trick here.

I'm closing this, and I've made a separate note to document the onExtraFieldData option.