diff --git a/rfcs/configure-file-name-from-block-meta.md b/rfcs/configure-file-name-from-block-meta.md new file mode 100644 index 00000000..4d19341a --- /dev/null +++ b/rfcs/configure-file-name-from-block-meta.md @@ -0,0 +1,87 @@ +# RFC: Configuring File Name from Block Meta + +## Summary + +Allowing code blocks to change the `filename` used in `eslint-plugin-markdown`'s processor using codeblock `meta` text. + +## Motivation + +Some projects use ESLint `overrides` to run different lint rules on files based on their file name. +There's no way to respect file name based `overrides` in parsed Markdown blocks right now using `eslint-plugin-markdown`'s parsing. +This RFC would allow code blocks to specify a custom file name so that `overrides` can be used more idiomatically. + +### Real-World Example + +In [`create-typescript-app`](https://github.com/JoshuaKGoldberg/create-typescript-app), `*.json` files _except_ `package.json` files have [`jsonc/sort-keys`](https://ota-meshi.github.io/eslint-plugin-jsonc/rules/sort-keys.html) enabled using [an ESLint config file `overrides`](https://github.com/JoshuaKGoldberg/create-typescript-app/blob/76a75186fd89fc3f66e4c1254c717c28d70afe0d/.eslintrc.cjs#L94). +However, a code block in a file named `docs/FAQs.md` intended to be a `package.json` is currently given a name like `create-typescript-app/docs/FAQs.md/0_0.jsonc`. +Short of hardcoding overrides or disabling the lint rule in the file, there is no way to have the `overrides` apply to the markdown code block. + +## Detailed Design + +This RFC proposes that code blocks be allowed to specify a file path in `meta` with `filename="..."`. +Doing so would replace the `filename` provided by `eslint-plugin-markdown`'s `preprocess` method. + +````md +```json filename="package.json" +{} +``` +```` + +Parsing would be handled by a regular expression similar to the [Docusaurus parser](https://github.com/facebook/docusaurus/blob/7650829e913ec4bb1263d855719779f6b97066b6/packages/docusaurus-theme-common/src/utils/codeBlockUtils.ts#L12). +The `title` meta prop name is intentionally the same as Docusaurus, so projects can use the same attribute for Docusaurus and ESLint. + +Parsed language is ignored when the codeblock provides a custom title. +Some languages have many file extensions, such as TypeScript's `.cts`, `.ts`, `.tsx`, etc. +Some extensions may map to multiple languages, such as Perl and Prolog both using `.pl`. + +Roughly: + +```diff +- filename: `${index}.${block.lang.trim().split(" ")[0]}`, ++ filename: titleFromMeta(block) ?? `${index}.${block.lang.trim().split(" ")[0]}`, +``` + +### Name Uniqueness + +Codeblocks must have unique file paths for ESLint processing. +If a codeblock has the same file path as a previously processed codeblock, it will have a sequentially increasing number appended before their extensions. +For example, given three blocks with the same name, would in order become: + +- `example`: `example`, `example-1`, `example-2` +- `example.js`: `example.js`, `example-1.js`, `example-2.js` +- `example.test.ts`: `example.test.ts`, `example-1.test.ts`, `example-2.test.ts` + +Alternately, if multiple code blocks require the same _file_ name, developers can give different _directory paths_ to ensure uniqueness: + +````md +```json filename="example-1/package.json" +{} +``` + +```json filename="example-2/package.json" +{} +``` +```` + +### Parsing Meta + +There is no unified standard in the ecosystem for parsing codeblock metadata in Markdown. +The syntax has roughly converged on the syntax looking like \`\`\`lang key="value", and to a lesser extent, using `filename` as the prop name. + +- [Docusaurus's `codeBlockTitleRegex`](https://github.com/facebook/docusaurus/blob/7650829e913ec4bb1263d855719779f6b97066b6/packages/docusaurus-theme-common/src/utils/codeBlockUtils.ts#L12): only supports a [code title prop](https://mdxjs.com/guides/syntax-highlighting/#syntax-highlighting-with-the-meta-field) like \`\`\`jsx title="/src/components/HelloCodeTitle.js" +- Gatsby plugins such as [`gatsby-remark-prismjs`](https://www.gatsbyjs.com/plugins/gatsby-remark-prismjs) rely on a syntax like \`\`\`javascript{numberLines: true}`. + - Separately, [`gatsby-remark-code-titles`](https://www.gatsbyjs.com/plugins/gatsby-remark-code-titles) allows a syntax like \`\`\`js:title=example-file.js. +- [`rehype-mdx-code-props`](https://github.com/remcohaszing/rehype-mdx-code-props): generally handles parsing of the raw `meta` text from the rehype AST. + It specifies syntax like \`\`\`js copy filename="awesome.js", with a suggestion of `filename` for just the file's name. + - [`remark-mdx-code-meta`](https://github.com/remcohaszing/remark-mdx-code-meta) is [referenced in the mdxjs.com `meta` docs](https://mdxjs.com/guides/syntax-highlighting/#syntax-highlighting-with-the-meta-field), but was deprecated with a notice to use `rehype-mdx-code-props` instead. + It also specified syntax like \`\`\`js copy filename="awesome.js" onUsage={props.beAwesome} {...props}. +- [`remark-fenced-props`](https://github.com/shawnbot/remark-fenced-props): A proof-of-concept that augments Remark's codeblock parsing with arbitrary MDX props, written to support [mdx-js/mdx/issues/702](https://github.com/mdx-js/mdx/issues/702). + It only specifies syntax like \`\`\`jsx live style={{border: '1px solid red'}} + +This RFC chooses `filename` over alternatives such as `title`. +`filename` appears to be the closest to a "popular" choice in existing projects today. + +## Related Discussions + +See #226 for the original issue. +This RFC is intended to contain a superset of all information discussed there.