Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configure file name based on block meta #226

Open
JoshuaKGoldberg opened this issue Oct 26, 2023 · 7 comments
Open

Configure file name based on block meta #226

JoshuaKGoldberg opened this issue Oct 26, 2023 · 7 comments

Comments

@JoshuaKGoldberg
Copy link

JoshuaKGoldberg commented Oct 26, 2023

Some projects use ESLint overrides to run different lint rules on files based on their file name. It'd be nice if the meta for a code block was respected in some way to retrieve file name, so that overrides can be used for code blocks too.

Right now, eslint-plugin-markdown always uses a name in this format:
https://github.com/eslint/eslint-plugin-markdown/blob/4d9f36f5c5fd1b5d3b1957913118cd76a92750f2/lib/processor.js#L299

Proposal: use a file name described by the code block's meta instead of index when possible?

Pending investigation: I don't know that there's a standard way to describe that file name. https://astexplorer.net/#/gist/0cce3ae28ac100aa5d78e3a88fdbf15e/e79a0e179def1bad1d8d7771f789709177c28a9a shows that the following codeblock's meta is the raw string "example abc=def" in remark:

```javascript example abc=def
console.log('!');
```

Context/example: in https://github.com/JoshuaKGoldberg/create-typescript-app, *.json files except package.json files have jsonc/sort-keys run: https://github.com/JoshuaKGoldberg/create-typescript-app/blob/76a75186fd89fc3f66e4c1254c717c28d70afe0d/.eslintrc.cjs#L94. In https://github.com/JoshuaKGoldberg/create-typescript-app/pull/986/files#diff-cc908ca4b57d59e44123c8b13deee7af64523aa40e21f69f11d4c604af276ff6R19 a codeblock intended to be a package.json is create-typescript-app/docs/FAQs.md/0_0.jsonc even with the meta. I had to manually disable the lint rule. I'd have preferred to instead extend the ESLint config's override to something like **/package.json.

I think this is a separate ask from #208. Not sure.

@nzakas
Copy link
Member

nzakas commented Oct 26, 2023

Proposal: use a file name described by the code block's meta instead of index when possible?

How would we guarantee a unique filename for each chunk? That's the main purpose of using the index.

@JoshuaKGoldberg
Copy link
Author

Hmm yes - so, 0-0-package.json, etc.?

@nzakas
Copy link
Member

nzakas commented Oct 27, 2023

Can you flesh out what exactly it is that you're requesting here? Should people be able to completely override the filename? (Like, if a block is js, should people be able to create a file that doesn't end in .js?) What is it you're proposing as the syntax for doing this?

@JoshuaKGoldberg
Copy link
Author

JoshuaKGoldberg commented Oct 28, 2023

Should people be able to completely override the filename?

On second thought: I think having it directly take the file name would be preferable. If an override wants to be configured for just package.json files (not *-package.json), I think there should be a way for the code block to specify that file name.

So I'm suggesting:

  1. Allow a code block to specify its file name with ```js path="name.ext"```
    • Paths: deep names may be specified, such as path="example-1/package.json"
    • Uniqueness: if a code block repeats a previously used path, eslint-plugin-markdown reports a parsing error
  2. Directly passing that path as the filename in the processor
    • If this isn't yet allowed, this would be blocked on me/us filing a feature request on ESLint core

(Like, if a block is js, should people be able to create a file that doesn't end in .js?)

I would be satisfied with ignoring block.lang if a path is specified. It'd be difficult to handle language variants such as .jsonc and .mts.

@nzakas
Copy link
Member

nzakas commented Oct 31, 2023

Allow a code block to specify its file name with js path="name.ext"

Is this already a convention that exists?

You've shared bits and pieces in this discussion, but I'd like to see a complete proposal, mini-RFC style, that explains exactly what you're envisioning, including how such a path would be augmented with an index (or not, but then how do we ensure unique filenames?).

@JoshuaKGoldberg
Copy link
Author

Sorry for the delay - sent #230 so we can chat in a bit more structured of a format. I tried pulling in references to related ecosystem projects but doubt I got all the potentially relevant ones.

@nzakas
Copy link
Member

nzakas commented Dec 8, 2023

Thanks. We are pretty deep in v9 work right now, so this may end up sitting for a while until we can get our heads above water.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Evaluating
Development

No branches or pull requests

2 participants