[RFC] project options using package.json

[eXon]

First, I have to say you are doing an awesome job on this project @vjeux and @jlongster !!!!

I believe this is related to #40 and #154

There is a big frustration when trying to use prettier: you don't know what are the project options. Even worse, if you are using the Atom plugin just like me, you're configuring it globally and honeslty, that sucks.

I know, you can format it your way and re-format it just before your commit and even automate this with some hooks. Honestly, it feels hackish. It just feels wrong.

Some people proposed to add a configuration file for prettier and it does seem like the core team don't want that. I can't blame them when looking at the root of my project, I have way too much files and adding one more would be silly. Especially considering prettier has no more than 7 options.

What I would like to propose is using the package.json file to be able to force options for your specific project. Prettier has only 7 options (love it that way) to override so it shouldn't be a big deal.

I made a proof of concept with the CLI using the working directory to search for the package.json. Within the editor plugins we could use the file directory to search for the package.json.

{
  "name": "my-package",
  // ...
  "prettier": {
    "singleQuote": true
  }
}

What do you guys think about that?

[vjeux]

Look at #918 for the proposal we want to go forward to but haven't actually started working on it.

[eXon]

@vjeux I'm happy we are on the same page. I don't know how I missed that issue. I would love to help with this because I think this PR is more than just a POC. It's the actual feature minus some optimizations.

I went to your proposal line by line and he's my though:

• Your proposal has the exact same format on package.json so that's awesome
• It search for the package.json depth first just like you proposed
• It stops at the first package.json with a prettier config (useful for people using things like lerna)
• There is no caching on the package.json, just plain old fs.readFileSync (can be interesting to implement later on)
• One major difference with your proposal is I don't intend to use the CLI for editors
• The responsibility of merging the user options with the project options would not be within the core but rather within the CLI and editor itself
• The core would contain a helper (getProjectOptions) to make sure we don't duplicate code
• The CLI could use the working directory as a starting point to find package.json (we might or might not have one or multiple filenames here)
• The editor would use the editing file as a starting point to find package.json
• Because we don't use the CLI with everything, no headache on how to make those calls faster

I don't know inside out the project so I might overlook some problems.

@vjeux Am I on the right track?

[SimenB]

This whole thing can be replaced by https://www.npmjs.com/package/read-pkg-up except for the part to keep searching if no prettier-entry

[SimenB]

Hah, or just https://www.npmjs.com/package/pkg-conf which is then even easier

[eXon]

@vjeux fixed a bug with non-undefined default options and using now pkg-config to get the package.json and dashify to convert the camelCase configs to dash so we can pass them to minimalist.

I've checked on NPM and they are widely used (over 300k and 500k download last month), still maintained and work very well.

[eXon]

Any update on this PR?

[vjeux]

Hey I'm sorry, I need to have a conversation with @jlongster about the exact steps we need to do. We've been focused on the clear cut things so far.

[eXon]

No worry, I know how time-consuming OS is.

[zimme]

Any updates on this?

[vjeux]

@zimme I haven't looked into it yet, but it's something that I do want to solve.

[simon04]

In #98 (comment), @thasmo suggest using https://github.com/davidtheclark/cosmiconfig.

[azz]

For those interested, I had a crack at implementing cosmiconfig in #2434.

[azz]

Closing in favour of #2434. Thanks for getting the ball rolling!