Support plaintext contentType

从所示的 defineDocumentType 配置开始，跟踪 contentType 如何被验证，以及文件内容如何到达 computedField；issue 没有指出 repository 中的文件或测试。要完成这项工作，需要就 contentType: 'plain' 的行为、其默认设置和向后兼容策略、文本与二进制内容的处理方式，以及相应的文档和测试达成一致。

I am trying to use .tsx files as input for a documentType. My use case is to turn them into JSON objects representing the associated components' properties via react-docgen-typescript.

The plan would be to have a computedField that uses react-docgen-typescript to parse the raw file content into a JSON object representing the properties.

But, Contentlayer doesn't support .tsxfiles, yet.

I tried this with the following config, assuming contentType: 'data' would just load the content of the files but was taught on Discord that it is only for frontmatter.

export const ComponentProp = defineDocumentType(() => ({
  name: 'ComponentProp',
  filePathPattern: `lib-src/**/*.tsx`,
  contentType: 'data',
}));

Proposed solution

Add a contentType: 'plain' that just loads the entire file and leaves processing up to the user.

This contentType would solve my use-case but even better, enable users of Contentlayer to use it for their use-cases which we are not yet aware of or that are needed by only a small minority.

Implications

Default contentType
Currently, Contentlayer treats files as markdown by default. Assuming we add a 'plain' type I would suggest changing this behavior to read files as plaintext by default. That, however, could be a breaking change!

I am not 100% sure how Contentlayer currently treats files but use-cases of people who currently parse non *.md files as markdown would be broken.

Plain text defaults
Going with the above Contentlayer would start to treat all file extensions it doesn't know as plaintext.
This implies that Contentlayer assumes to be used on text files only. It would lead to errors when handling binary file types, such as jpg or mp3.

There should be documentation and logging around this fact. The question here is whether Contentlayer could confirm that a file it is processing is a text file or not?

Alternative implementation

A backward-compatible way of introducing plaintext file types would be to add a contentType: 'plain' as an additional, optional feature to use.

However, I could see people getting confused by having a plaintext interpretation available but this not being the treatment that Contentlayer default to.

Ont he other hand, Contentlayer is a system for handling content and might find it's audience largely in people processing markdown files which would justify leaving the default interpretation as markdown.

Open questions

• Is defaulting to plain text a good idea?
• Can we determine a file to be a text file?
• Should we potentially switch to requiring conentType to be set explicitly?