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
Configuration file support #62
Comments
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 |
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. |
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 |
@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? |
@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. |
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
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 has some ideas about this. I think a simple solution could be for an editor plugin to search for |
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. |
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:
You can then do:
|
@kusold you're a lifesaver 🖐 |
@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 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. |
@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. |
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... |
@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 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:
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... |
@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. |
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. |
This is going to happen. We're working out the details right now |
@vjeux If this is going to be It's not a well adopted standard yet, but the more projects that do this, the more widespread it will become. |
I'd prefer, like all projects everywhere else, for my config dotfiles to remain at the root of the repo. |
I think that's a misunderstanding @ljharb the suggestion is not to only look in a |
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. |
@ljharb ls does, but github doesn't, and yes, that's the way it would work. |
As of #2434, the current default won't search |
I think it would be valuable to support for some type of file that contains prettier's config so that projects can check it in source control.
I can see 2 cases where this would be useful.
Could be it's own file (something like
.editorconfig
) or maybe part ofpackage.json
.The text was updated successfully, but these errors were encountered: