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

Feature Request: Support for Better Pretty-Format JSON #40

Closed
Skylion007 opened this issue Oct 1, 2020 · 1 comment
Closed

Feature Request: Support for Better Pretty-Format JSON #40

Skylion007 opened this issue Oct 1, 2020 · 1 comment

Comments

@Skylion007
Copy link
Contributor

While the default pre-commit hooks has a pretty-format JSON hook, it is has some serious customizability/prettifying issues that seem to be out of scope: pre-commit/pre-commit-hooks#521 and there is blocking my adoption of using that. Perhaps adding a more feature-ful, customizable JSON prettifier to this repository would be appropriate.

@CAM-Gerlach any interest? This blocks my auto-formatting of JSONs.

Since JSONs can't have comments we don't have to worry about #26 at the very least. Perhaps there is an easy fix in JSON.dumps that I am unaware regarding spitting out short-arrays.

@macisamuele
Copy link
Owner

@Skylion007 I would be against having redundant pre-commit hooks.
Additionally having tools with many configurations usually leads to have very custom formats that goes beyond the idea of having a "standard" way of formatting the file (examples are the black formatter or go fmt which give almost no configuration options).

This repository was initially introduced to provide a sort of opinionated way of formatting/making-prettier some formats that were not supported by the default pre-commit hooks (pre-commit/pre-commit-hooks#307).

Said so, I have no plans on supporting customised JSON formatting (especially considering that the added work would have, in my opinion, very limited adoption).

Sorry, if this might not look like the answer you were looking for but we would like to focus on what makes developers effective and not opening the way for internal discussions as "I want arrays to be split", "I want this line length", etc.

Still, if you feel like this is important for your usecase you can:

  • create the formatting rule as local rule so you can test it out
  • [eventually] open a PR to this repo and we'll be checking what impact it is introducing in terms of size as well as maintenance costs

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

No branches or pull requests

2 participants