Format package.json like Prettier does, by default

[ematipico]

Solution

I added it one week ago. We should take care of still allowing users to set formatting options for package.json in overrides. In fact, we could encode the package.json default formatting as the first overrides. This allows user overrides to override this one.

[prescottprue]

Could be nice as a default - for anyone looking in the meantime, as called out in other threads this override provides expected results:

"overrides": [
    {
      "include": ["**/package.json"],
      "formatter": {
        "lineWidth": 1
      }
    }
]

[dyc3]

Technically, the correct way to do this is to match prettier's json-stringify formatting. AFAIK, json-stringify is literally the output from JSON.stringify() with indentation. I learned this from the discussion in #3670. Changing the line width like above is an easy hack though.

We could:

• Introduce a new json formatter option to control the behavior (set to either default or json-stringify), and treat package.json as a "well known" file and default it to json-stringify
• treat package.json as a "well known" file, and inject the above override transparently

The latter would obviously be the easiest to implement, but I have no idea if it would make the formatting align completely with JSON.stringify(). Regardless, we should take a look at what exactly JSON.stringify() does for pretty printing.

[ematipico]

I tried the override trick, and it doesn't scale well. Plus, it gets in the way of other tools like migrate eslint

[ematipico]

I am more convinced that we should purse this proposal

#674

Why? It follows the philosophy that we're pursuing, where the formatter is opinionated and it's language agnostic.

For this particular case:

• cosy: it will format the package.json like prettier and npm do
• compact: mainly it will format the JSON file like today

[Conaclos]

I tried the override trick, and it doesn't scale well. Plus, it gets in the way of other tools like migrate eslint

Actually I was thinking about an implicit override that is always here regardless if overrides is specified or not.
overrides complements the implicit one.

I am more convinced that we should purse this proposal

I have to admit that I am not convinced by this proposal because we lose granularity.
There are also not that many formatter options.
If we keep both individual options and this new system, I am skeptical that users will adopt it.

[ematipico]

@Conaclos that's exactly what I did, and it doesn't work very well.

It can't be used as a default value of the configuration because it gets in the way of the migration command, it gets printed at the end.

[Conaclos]

It can't be used as a default value of the configuration because it gets in the way of the migration command, it gets printed at the end.

Could you expand on this and/or provide an example? I don't understand what you mean.