Configuration file support about prettier

[jlongster]

We aim to be zero-config. For now at least, I am against this. The few existing config options only exist to help applying to existing projects, and should only be used if you really need to. We will see what happens over time, but for now I'll point you to #40

[ljharb]

The problem is that not everyone will adopt a tool like this all at once, thus the "generic format" for text needs to match the project's existing conventions. Disallowing config will mean that adopting prettier is an all-or-nothing approach, unless the project just happens to already comply with the convention prettier chooses, which - for the exact reasons you mention that the ecosystem could benefit from this tool - will prevent adoption of it, on any larger scale.

[kusold]

My use case is that at work the coding convention is different then the coding convention I prefer for personal projects, and I need prettier to integrate with my IDE.

Here is my hack for adding a configuration file for prettier:

❯ cat .prettier  
--no-semi --use-tabs

You can then do:

❯ ./node_modules/.bin/prettier $(cat ./.prettier) $file

And here is my IntelliJ External Tool configuration:

[joshburgess]

I have to say it doesn't make much sense to require each and every editor to setup a prettier config individually. It really should be editor independent. Some people want trailing commas, no semis, single quotes, etc... If a project sets a list of these rules, contributors have to manually setup the proper rules to match the project according to the maintainers' preferences, which doesn't make sense. These rules should already be set for them by a configuration file in the project so that anyone using any editor doesn't have to do any extra setup to adhere to the project's style...

[jlongster]

Would you consider a pull request that added support for a .prettier config file, defaulting to the current behaviour in it's absence?

Not at this point in the project. I'd really like to avoid it, as explained below. Never say never, but this project is only a few days old, and my preference is to evolve slowly. If we can solve problems a different way that don't require an additional piece of infrastructure, everybody wins.

There are already so many project-level configs. While we are sorting things out, an atom plugin itself could read from a .prettier file and the community can try it out without us supporting it natively yet.

What I want is a file to store settings in so I can use the atom plugin/cli without issues even on projects that do not use the defaults for every config option.

Here's the real reason I don't think we need it: you shouldn't have to worry about what settings the project has. One of the hidden benefits with this kind of printer is that we're closer to the ideal where text is stored in a generic format and you can view it however you like. Another project has different settings than you? Who cares! Just open a file and format it according to your preferred settings. When you go to make a commit, the project should have a way to auto-format the changes files back to its own preferred settings (we'll work on this toolchain soon).

I think the JS ecosystem could hugely benefit from this given that it's probably the most diverse group of opinions because it's so large. It's a chance to end the endless debates because it doesn't matter what's committed anymore: you can reformat and read code in your preferred settings, and reformat it back before committing. Worst case if some unformatted code gets through, the CLI will fail when it checks to make sure everything is formatted in the "formal" way.

[vjeux]

This is going to happen. We're working out the details right now

[ForbesLindesay]

@vramana I'm not asking for more configuration options. I'm happy to just enable/disable trailing commas across the board.

What I want is a file to store settings in so I can use the atom plugin/cli without issues even on projects that do not use the defaults for every config option.

[mbrookes]

@vjeux If this is going to be .prettier or similar, please consider searching in the .config directory in the project root, (a place for large projects with many config files to store config files to tidy up the root directory).

It's not a well adopted standard yet, but the more projects that do this, the more widespread it will become.

[ForbesLindesay]

I would very much like this tool to be configureable. In particular, I use trailing commas in files that are compiled via babel, but it's not an option (in function calls) for files that are not compiled.

I do think it should work, and do something people are mostly happy with, without a config. It seems to mostly do that, which is great.

I also think we need to make sure that if you're using something like create-react-app, it just works out of the box.

Would you consider a pull request that added support for a .prettier config file, defaulting to the current behaviour in it's absence?

[joshburgess]

@k15a That's an interesting perspective, but it's very different from what I would want, personally. I don't see a lot of value in writing in one way (ex: my personal preference), and, then, on commit, having my code transformed into the project's preference. This adds complexity I don't want to deal with. It's much simpler for the code to exist in one style for all who see it. I want to read the code 6 months later in exactly the same style I wrote it in originally, as it makes things easier to understand and easier to maintain. Perhaps, people working at huge companies (like Facebook) have a different perspective, but I don't think that same mindset applies to most people working on smaller open source projects.

Realistically, prettier will not be able to replace ESLint for many people. ESLint is able to catch things that go beyond style & formatting, e.g., catching code that doesn't adhere to best practices or library-specific details. I think myself & many others aren't looking for prettier to eliminate linting altogether, but just to use it alongside of ESLint to take care of the auto-formatting issues that ESLint can't handle.

There are also very practical reasons for requiring a single project-level config:

1. Does a given project even use Prettier? (Like you said.) If not, disable it immediately.

2. Some people use multiple editors. For example, I often use both Atom & VSCode interchangeably. It's painful to have to keep multiple editor-specific settings synced, and if I decide to try out a new editor for whatever reason,, I then have to go and do it yet again.

3. Even ignoring people who use multiple editors, many people will use both 1 editor and, at least occasionally, also the CLI (perhaps, to format code that somebody else submitted through a PR?). Having your CLI unaware of your editor settings for prettier is just painful and not very practical. It's forcing a ton of extra configuration burden onto the user when the stated goal was to do exactly the opposite.

As others have mentioned, we already had a couple of very popular, somewhat standard stylistic settings available in StandardJS and Airbnb's ESLint config.... Prettier having yet another set of opinions that differ from those (in certain cases) while also not being easy to configure wholesale (i.e., only one time, in one place, per project) means that it is not easy to integrate into existing projects where people are already being very strict & careful about style & formatting. For me, that meant setting up prettier ended up being more trouble than its worth, and I just decided to uninstall...

[janicduplessis]

I like the idea of having no or very few config, but would also like a way to tell tools that a project uses prettier (see my first point). I feel like this is needed if we want to adopt auto formatting progressively for JS. We cannot do like Reason or Go did because these languages had something like this from the start so every project uses them and there is no need to tell tools if auto formatting should be used.

[jlongster]

I like the idea of having no or very few config, but would also like a way to tell tools that a project uses prettier (see my first point).

@vjeux has some ideas about this. I think a simple solution could be for an editor plugin to search for node_modules and check it prettier exists within it. We don't need a config file just to see if a project uses it.

[joshburgess]

@k15a For whatever it's worth, I'm reading this thread #1086 right now, and it seems to offer a promising solution.

That sounds good to me. I don't really care if it's a standalone config file or a few lines in the package.json, as long as it solves the problem.

[MrLoh]

Is this still something that's ever gonna happen. I would be all for one way to write JS, but that's just not how the world works these days. Prettier has boiled it down to very few options though which is great. My problem is that I am working for different people and in one project they insist on semicolons and in the other they insist on no semicolons. It's not up to me to decide, so the only way around not having to go to the prettier atom settings every time I work on a different project would be having settings. Maybe they could be just inside the package.json, I don't care, but this is really cumbersome if you don't just work in one environment.

[azz]

As of #2434, the current default won't search .config directories, but you can pass prettier --config .config/.prettierrc to the CLI.

[kusold]

@oztune Probably the best option for you is to fork prettier-standard-formatter and set your own config options here. Publish to npm when done for easy sharing.

Alternatively, using my comment above, you can create config files, then use npm scripts to run prettier.

[MrLoh]

I think that's a misunderstanding @ljharb the suggestion is not to only look in a .config dir for a config file, but to look in this dir additionally to of course looking in the root dir.

[vramana]

@ForbesLindesay @jlongster has said in another thread the he may consider allowing an option to configure function trailing commas.

Have you seen this https://github.com/kentcdodds/prettier-eslint?

[kitze]

@kusold you're a lifesaver 🖐

[oztune]

Here's the real reason I don't think we need it: you shouldn't have to worry about what settings the project has. One of the hidden benefits with this kind of printer is that we're closer to the ideal where text is stored in a generic format and you can view it however you like.

@jlongster I understand why you're trying to avoid project config options. I love the idea that each developer can view the code-base of a project with any formatting rules they prefer, but the repo keeps all the code formatted the way the project prefers.

But... we have a different use-case that may require them. We have multiple separate projects, each in its own repo, and we want all the projects in our organization to share the same prettier rules (which are different than the default). Is there a way to share them that's DRY and doesn't require copy-pasting them across repos?

[oztune]

@kusold Thanks for that link! Both of those are very practical solutions, but I'm also interested to hear from the authors if they intend to address this need formally.

[k15a]

@joshburgess In my opinion it totally makes sense. Editors should format the code in your personal preference and then the code should be reformatted in the preferences of the project when you commit the files to the repo.

That's also the main reason I would like to have a prettier config because I can then configure my editor plugin to only format on save if I am in a project which uses prettier. Currently I have to disable prettier manually every time I work on a project which doesn't use prettier.

[k15a]

@joshburgess Very good points. Maybe the editor integrations should have an option to format with the project specific preferences or format in your own style.

I think that people should stop using ESLint for styling related issues because prettier handles them better. In the other hand ESLint is pretty good at catching common errors like no default case in switch or unused variable.

[ljharb]

I'd prefer, like all projects everywhere else, for my config dotfiles to remain at the root of the repo. ls hides dotfiles by default, so there's no need to "tidy up" anything.

[ljharb]

Thanks for clarifying, as long as it prioritizes "root" over "root/.config", I'd have no objection to it looking in ".config" for those who prefer that style.

[mbrookes]

@ljharb ls does, but github doesn't, and yes, that's the way it would work.