Support EditorConfig

[wooorm]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Problem

EditorConfig defines certain code-style preferences.
Some of those can be done by the engine (charset, insert_final_newline).
Others by the processor (syntax-tree/mdast-util-to-markdown#51, syntax-tree/mdast-util-to-markdown#50; what about HTML though where the whitespace is part of the AST?).
Some are ambiguous (end_of_line).

Solution

Can we load (as an option), editorconfig files, and pass their keys, camelcased, to settings?
That passes them to *-parse and *-stringify.
We could pass a nested object if there’s fear that it would conflict, but I don’t think it does?

Alternatives

• Custom adapter functions (e.g., passed by remark-cli to the engine) that transform an EditorConfig into certain settings? Could be modules, e.g., called editorconfig-to-remark-settings or so?

[ChristianMurphy]

👍 on having a way to pull outside settings to inform how to generate output.
👍 on editorconfig as one of them.

I'd be cautious on hard coding it to be editorconfig exclusive.

Custom adapter functions (e.g., passed by remark-cli to the engine) that transform an EditorConfig into certain settings? Could be modules, e.g., called editorconfig-to-remark-settings or so?

I'd lean towards this.
It would be good to leave an opportunity to read the same values from vscode settings, prettier config, dprint config, etc.

[wooorm]

I see remark/rehype as formatters on the same level as prettier or dprint.
EditorConfig is a tool under them. VS Code is a tool that uses them.
So my idea of the settings flow is editorconfig -> remark/rehype/prettier/dprint -> vscode?

[ChristianMurphy]

EditorConfig is a tool which tries to standardize settings across editors, but like many post-facto standards, not everybody uses it

EditorConfig may be a good default, but it is not the only configuration option out there, with each editor having their own settings file which the information could be pulled from.

I see remark/rehype as formatters on the same level as prettier or dprint

It somewhat is, that said, remark/rehype could be configured to automatically generate content more similar (not identical) to how dprint or prettier would.

[wooorm]

I don’t understand, so perhaps these questions can help me understand:

• How would remark-stringify support prettier or any other tool’s config?
• Should remark-stringify read the .vscode settings which vscode already passes to it and which take precedence?
• How many tools should be supported in unified-engine/*-stringify?
• What’s to decide whether or not an arbitrary tool is supported in unified-engine/*-stringify?
• Would it not be easier to use standards (i.e., EditorConfig)

[wooorm]

I especially don’t understand the meme here. There is but one standard for sharing settings across editors and tools: EditorConfig.

[ChristianMurphy]

Each editor has its own standard, which it and maybe a few others follow.
EditorConfig created yet another, it started independent of other editors, it needs a plugin installed, which not many developers do.
Especially not since the rise of having formatting as an external tool (like prettier).

That's not to say editor config is bad, just that it isn't universal, and potentially growing more niche (currently).

[wooorm]

I don’t think that tools should be called standards. Prettier is not a standard. Chrome is not a standard. EditorConfig is a standard.

Prettier, VS Code, and other tools support EditorConfig. I’d like to support it too.
Prettier does not support VS Code. dprint does not support prettier. I don’t think we need to support VS Code or prettier.

Can we focus on the other parts of the issue too? Perhaps by looking at the questions I asked in my last comments, and seeing how EditorConfig/prettier/VS Code/dprint can solve them?

[ChristianMurphy]

Can we focus on the other parts of the issue too? Perhaps by looking at the questions I asked in my last comments, and seeing how EditorConfig/prettier/VS Code/dprint can solve them?

Did you read my previous answers? They addressed most of your questions before you asked them, to re-iterate for your convenience.

How would remark-stringify support prettier or any other tool’s config?

Through a settings plugin, which reads a configuration file from another tool, and translates it to remark settings.

Should remark-stringify read the .vscode settings

A settings transform would

which vscode already passes to it and which take precedence?

settings plugin would likely be lowest precedence

How many tools should be supported in unified-engine/*-stringify?

As many as the community wants to create plugins for, starting with one, editorconfig.

What’s to decide whether or not an arbitrary tool is supported in unified-engine/*-stringify?

Whether someone feels like creating a settings plugin

Would it not be easier to use standards (i.e., EditorConfig)

Maybe, again standardized is not the same widely-adopted.
If your target audience is the JS community, and specifically Sindre, go for it.
If the target audience is the broader developer community, more flexibility may be needed.
(for example peruse through https://github.com/apache and you'll find more intellij configurations than editor configs)

[wooorm]

Did you read my previous answers? They addressed most of your questions before you asked them, to re-iterate for your convenience.

No need to be (passive) aggressive.

How would remark-stringify support prettier or any other tool’s config?

Through a settings plugin, which reads a configuration file from another tool, and translates it to remark settings.

This answers how custom config can be loaded. I am interested in how you would see such a plugin, sure, but I am particularly interested in what benefit remark-stringify has of being given prettier settings or VS code settings.

In the original post, I describe that remark-stringify (and rehype-stringify, and others) can benefit from charset, insert_final_newline, end-of-line, indent-style, indent-size, tab-size, which are found in EditorConfig files.
Are there any particular fields that are found in Prettier or VS Code, that are not found in EditorConfig, which you want to pass to all *-stringify packages?

Here you propose a unified plugin, which could exist in userland, that is connected to a certain tool or editor, and to remark. This proposed plugin does not work with the engine, so it seems out of place of the discussion here in this issue tracker?

If your target audience is the JS community, […], go for it.

I do indeed see the target audience of unified as the JavaScript community, yes.

[ChristianMurphy]

Did you read my previous answers? They addressed most of your questions before you asked them, to re-iterate for your convenience.

No need to be (passive) aggressive

I'm responding to you stonewalling concerns with a wall of tangential question, any of which go unanswered you'll ignore the over arching concern.

Here you propose a unified plugin, which could exist in userland, that is connected to a certain tool or editor, and to remark. This proposed plugin does not work with the engine, so it seems out of place of the discussion here in this issue tracker?

To repeat and make it very clear, I'm currently 👎 on this being a part of unified engine, this should be in userland, for the variety of reasons stated before.

Are there any particular fields that are found in Prettier or VS Code, that are not found in EditorConfig, which you want to pass to all *-stringify packages?

Potentially yes, I don't have any specific fields in mind.
This misses the broader points though:

• editorconfig should not be made a requirement for a project that doesn't use editorconfig.
• having an editor configuration implicitly change the default behavior of an unrelated build tool is highly unexpected.

I do indeed see the target audience of unified as the JavaScript community, yes.

It is also adopted in the Python community (often via pre-commit) and at times in the Java community via gradle/maven plugins.
I'd also consider these part of the target audience.

[wooorm]

I'm responding to you stonewalling concerns with a wall of tangential question, any of which go unanswered you'll ignore the over arching concern.

This last phrase is ungrammatical, I don’t understand what you mean. Can you rephrase it and explain what you see as the “over arching concern”?

Stonewalling is, apparently, the act of avoiding conversation. I have questions. You don’t answer them.

To repeat and make it very clear, I'm currently 👎 on this being a part of unified engine, this should be in userland, for the variety of reasons stated before.

On the point made in this paragraph: this point is new. You are changing the goal posts. Previously you advocated for other things than editorconfig. Now you advocate against configuration files.

On your vote: the unified collective uses a consensus-seeking approach, you are supposed to build consensus and to work on an acceptable solution (https://github.com/unifiedjs/collective/blob/main/decisions.md#initiatives).

This misses the broader points though:

• editorconfig should not be made a requirement for a project that doesn't use editorconfig.
• having an editor configuration implicitly change the default behavior of an unrelated build tool is highly unexpe

These points are new. They are solvable. We could have a dialogue on how they can be solved.
I am not arguing to require editorconfig. Like prettier, editorconfig could also be optional instead of required. I don’t buy the gut feeling that config files are unexpected though.

[ChristianMurphy]

“over arching concern”?

That editorconfig should not be the single editor language supported nor should it be enabled by default.

Stonewalling is, apparently, the act of avoiding conversation. I have questions. You don’t answer them.

I have answered each of them.
Often quoted to ensure clarity that it has been answered.
Gaslighting is not appreciated either.

Stonewalling in a deflecting sense, you go on tangents about your definition of standards, re-ask questions which have already been answered previously (or by the issue itself even), seemly to avoid the conversation of why this is needed as a core feature, and not in userland/a plugin.

Previously you advocated for other things than editorconfig. Now you advocate against configuration files.

I'm advocating for both supporting more configuration languages, and not enabling this by default/in unified engine.

On your vote: the unified collective uses a consensus-seeking approach, you are supposed to build consensus and to work on an acceptable solution (https://github.com/unifiedjs/collective/blob/main/decisions.md#initiatives).

Thanks for linking to the guide.
It's a good reminder.
Since this significantly impacts multiple projects and multiple organizations, it should, according to the decision process be an RFC.

These points are new. They are solvable. We could have a dialogue on how they can be solved.

Great, share the intended solution.

I am not arguing to require editorconfig. Like prettier, editorconfig could also be optional instead of required.

As a part of unified engine?
The engine currently provides a way to manage plugins and reporters, but it doesn't really have user facing settings.
How would it be optional to enable?
How would it be optional to download (or not download)?

I don’t buy the gut feeling that config files are unexpected though.

A potential scenario.
Unified engine enables editor config by default.
Locally I have configuration files for developing (.editorconfig for example).
But when that goes to CI, only files to be used in build/test are sent to the CI server, not development files like .editorconfig, prettier config, vscode settings, etc.
Tests on CI leaning on unified engine would produce different results, and fail tests.
And even more confusing, if editor config is on by default in unified engine, there would be no clear indication that it was used to change results.