Non-Standard Key Support

[Drakmyth]

Hi. I'm a newcomer to both Prettier and EditorConfig but am liking what I'm seeing with both of them. I just wanted to throw another vote out for being able to support keys not defined in the EC spec from the .editorconfig file. I saw (#9) and (#21) were already closed on this topic, but I wanted to provide some additional points in support I came across and wasn't sure if an already closed ticket was an appropriate place to continue the discussion.

Reading editorconfig/editorconfig#415 and editorconfig/editorconfig#60 (comment) it looks as though the expectation from the EditorConfig team is that tools would be able to read domain-specific or even tool-specific properties from the .editorconfig file that aren't necessarily defined by the EditorConfig spec.

It also looks like ReSharper (and other JetBrains tools) and Roslyn both heavily support custom keys for configuration.

My use case is currently very small - the only non-standard key I wish to configure right now is the bracketSameLine option - but it's annoying that I either need to have two separate config files (.editorconfig and .prettierrc) or have to move away from EditorConfig entirely to do so.

Not sure if this moves the needle on adding support for this or not. I'm nearly always on the train of not adding custom extensions for things so while my initial thought was the same as expressed in (#9), seeing that the EditorConfig team is actually encouraging the practice changed my mind and seeing these issues I wanted to make sure others were aware too.

[fisker]

Personally, I don't think support non-standard keys is a good idea.
Note: there is an open PR about quote_type support in Prettier prettier/prettier#12780

[josephfrazier]

hey @Drakmyth, thanks for continuing this conversation! I appreciate all the links you've provided that indicate existing intention and implementations of parsing non-standard/custom properties. It seems like this question might not be as simple as I thought it was previously.

@fisker, thanks for chiming in as well!

As you (@fisker) mentioned in #16 (comment), this package was originally intended for use by Prettier, and while there are some other dependents (according to github and npm), Prettier is still the vast majority of the usage this package sees.

Given that, I think it might make sense for this package's code/functionality to move into the Prettier repository, so that any issues relating to it can be discussed where it's used. Personally, I don't use .editorconfig with Prettier, so I don't feel especially well-positioned to make decisions on how things should work, especially when the output of this package is subsequently modified by Prettier (I think you had also mentioned this previously, @fisker), indicating that its behavior is already divergent from the intended use case.

What do y'all think of that proposal? If we have https://github.com/prettier/prettier/ vendor this repository's code, then I can archive this repo and direct people to discuss functionality in the Prettier issues.

[Drakmyth]

Makes sense to me. When I started using Prettier, given EditorConfig support was called out in the docs I was expecting that support to be managed by https://github.com/prettier/prettier/. It was only while looking through that repo for other EC-related issues and discussions that I learned about this repository and that the maintainers over there seemed to largely be directing any EC-related issues here, hence my posting this issue here instead of there.

If the Prettier application is already modifying the configuration this package provides, I question the benefit of this being separate. At the least it seems like it should be maintained by https://github.com/prettier, and the question of whether it should remain as a separate package/repository or be merged into the Prettier codebase completely can be answered separately once they're maintained by the same people.

[josephfrazier]

Makes sense to me. When I started using Prettier, given EditorConfig support was called out in the docs I was expecting that support to be managed by https://github.com/prettier/prettier/. It was only while looking through that repo for other EC-related issues and discussions that I learned about this repository and that the maintainers over there seemed to largely be directing any EC-related issues here, hence my posting this issue here instead of there.

Thanks for the context, I definitely agree with you opening the issue here, given that this is where things are currently implemented 👍🏻

If the Prettier application is already modifying the configuration this package provides, I question the benefit of this being separate. At the least it seems like it should be maintained by https://github.com/prettier, and the question of whether it should remain as a separate package/repository or be merged into the Prettier codebase completely can be answered separately once they're maintained by the same people.

That's what I'm thinking, this is better suited to be maintained as part of the broader Prettier maintenance effort, rather than being off to the side in its own repo. @fisker is the primary committer to Prettier currently, let's see what they think!

[fisker]

so that any issues relating to it can be discussed where it's used.

Make sense to me, we can move the code to Prettier I think. Unless @sosukesuzuki have a different opinion.

[josephfrazier]

Thanks @fisker! As you noticed, I'm working on this in prettier/prettier#15394. Once that's merged, I'll plan to close this issue (and #16) and ask @Drakmyth to re-open it in the Prettier repo

[josephfrazier]

Ok @Drakmyth , prettier/prettier#15394 was merged, so if you would open this issue in the prettier repo, the conversation can continue there