RFC - Future of Prettier and (re)considerations about current mindset #8507
Comments
|
Disclaimer: I'm not a contributor or maintainer of Prettier, just a user. I feel like Prettier's vision is already basically what you're describing, the only difference being the specifics of what "readable" and "maintainable" consist of.
Perhaps this is the main point of contention?
The Prettier maintainers already try hard not to decrease code quality/readability. :) As you can probably tell, I'm a very happy user of Prettier. A big thanks to the maintainers. |
|
I don't see how this barrage of accusations is constructive. I'll close this issue in a couple of days unless other contributors have something to add. |
I'm sorry if you feel this is a "barrage of accusations", it's not meant to be. The above is an attempt to point out a relatively small subset of related issues, in regard to how the current Prettier rules could be better at increasing code quality and increase adoption. It also highlight how to better handle breaking changes. It's meant at being constructive (did I fail at that?)
I don't feel that way. I'm not saying Prettier didn't do anything about improving PR reviews, but I'm saying it could be improved. There are many issues under Therefore, my feeling is that the intent is not clear, despite the fact those improvements would increase the code quality. Thus, it feels like it's not the main purpose of Prettier to increase code quality. (but rather feels like a secondary motive, like a "nice-to-have" thing) |
Totally. Basically, what you wrote is: "Prettier is garbage, please consider making it less garbage".
How is this not trolling? |
|
I'm sorry about that, really. My comment (in the other issue) was motived by frustration and happened days before opening this RFC here. I've had time to change my mindset between both events, basically going from frustration to "see how to improve things". But, if you have read both at once (as I believe you did), then it must be hurtful indeed. So, I apologise about my harmful words towards the Prettier teams and maintainers in general. Those weren't nice things to say and I regret the tone I've used back then. I hope we can lead this discussion forward, and can assure you it's not a "troll". |
|
I don't understand what is to discuss here. Just the fact that Prettier isn't perfect? |
|
There have been many discussion regarding multi-lines (objects, JSX, arrays, etc.) and it feels like you are undecided about to do about those. How do you see Prettier evolve in the future? Do you want Prettier to help about the above mentioned issues? PR like #6644 are awesome-looking, seems proper, useful, without conflict, the author took a very special care to keep it clean, and yet it's not merged. Why so? Is it because you're undecided about those? (could be many different reasons, and it's just an example) Prettier never states anywhere in the website that it's meant to improve code quality, or readability (AFAIK). In a word, what are your motivations (as core member) regarding Prettier? |
|
/cc @thorn0 Maybe we can create I think it's just a misunderstanding between developers and contributors. Some issues not solved for years, and we do not give an official answer. We just say it's still in discussion. But I think this is very bad. Honestly, I would rename this issue - I can understand the developers here, I am waiting for some fixes (not only in prettier) for a long time and lack of response annoying, for example I offered my help in support http2 for express about a year ago and received no response. This is the problem of any OSS project. But we can solve it. What do we need to solve? Set time limits for response. Some limits:
I would like to hear your opinions. |
|
This could all be solved by an open option / plugin system. Maybe we could direct our attention to such a thing ? |
|
Adding options has a cost. If we added an option every time there was a place where some people believed a different behavior would be more readable, a great deal of Prettier's value would be lost. In general, the main reason issues remain open is because there is disagreement about which behavior is more readable, not because the requested behavior is objectively better but Prettier doesn't want to make the change. That's the case with all of the issues you raise. (Sometimes it's because no one has come up with a good way to implement the new behavior, but that's rare.) I do think there's value in prioritizing issues based on their effect on readability. But I strongly disagree with the idea that Prettier should add an option to enable different behavior just because some people would find the that behavior more readable. (Disclaimer: I am not a core maintainer.) |
|
@evilebottnawi The issues in question are option requests or requests to change formatting in accordance with someone's preferences. In my opinion, it's time to make the option philosophy stricter and close those issues (as wontfix). They were left open mostly just in case someone arrives with a stronger argument for or against the proposed change than what was said before. If time goes and nothing like that happens, it makes sense to close the issue. |
|
@thorn0 For most, yes, but we should go through each issue and give answer + maybe we should think more about library based plugins |
Most of the issues in regard with "multilines" (arrays, objects, JSX props, etc.) are not based on "someone's preferences" but on actual readability and code quality.
Multiline is very important for code readability/quality and ease of PR reviews. It goes beyond personal opinion at this point. Doesn't it? It's not about adding an option for this, it's about making it the new default, because it's been proved it's just better. |
|
@Vadorequest What you call "multilines" is the basic functionality of Prettier: split long lines, collapse short lines. If people don't need that, if they want to preserve their manually crafted line breaks, they don't need Prettier. ESLint's formatting rules should suffice for them. |
No. You might find it more readable one way, but other people can disagree. There are not, in general, objectively correct answers to questions of style. |
Prettier provides lots of other benefits that ESLint doesn't. (That's the main reason why I'm personally interested by Prettier.) Also, Prettier is about the code formatting (make code more consistent in itself and across team members) while ESLint is a linter and it's rather about the code quality (detect problematic code patterns that could lead to potential bugs). Their purposes are fundamentally different, as explained by this article. |
|
Just some insight: Prettier <v-btn color="primary" rounded text x-small class="mr-2" @click="removeItem(item)">Webstorm / Pycharm <v-btn color="primary"
rounded
text
x-small
class="mr-2"
@click="removeItem(item)">If the line was further up the tree (further away from line braking point) it would be longer. |
|
I think that instead of pushing for new/different defaults (stalled because some people prefer one way while others another, among other reasons) or adding new options (stalled because of the general policy of not introducing new options) I believe the way to go forward would be with the introduction of a plugin system. I can then easily image having |
|
There hasn't been much discussion within the past 2 weeks, but if I were to summarize what's been said so far:
I haven't got much feedback regarding Prettier owns motivations so far. "But, what drives you? What is your goal? What are your rules for "we should do this over that"? In a word, what are your motivations (as core member) regarding Prettier?". We obviously have different opinions about what makes code more maintainable/readable, and I've come to the conclusion that Prettier's own motivations are no different from anyone's, you defined rules based on your own personal preferences/beliefs and made those rules the default/locked behaviour and force people to follow them. That's what's meant by "Opinionated code formatter". I haven't seen any tangible guidelines regarding how to resolve a conflict, when there are multiple ways of doing something, each with their pros/cons. Eventually, you pick one way over others, because you believe it's better overall. #8507 (comment) I'm not saying it's easy to decide what behaviour should be selected over others, I'm just saying there doesn't seem to be official/transparent guidelines being followed when doing so. I'm concerned you may be mistaken when believing devs have a lot of options regarding code formatting. We simply don't. Prettier is very different from a Linter (like EsLint), and really isn't meant to provide similar functionalities. There aren't much alternatives to Prettier out there, at the moment. (EsLint is not) And that's probably a reason why there are so many open issues about missing features, because Prettier doesn't provide what's expected by many developers (and it's its right to do so), who are often looking for a tool that can be configured/extended, similar to what EsLint provides. And since you don't want to provide such configuration, I believe it's time to make it official and close all issues you don't intend to fix, so that the community is aware of this decision and can move towards another alternative, for those who aren't satisfied by Prettier. |
I think it is important to understand that how we layout information whether it be in a printed medium or in a codebase, the indentation, line returns, and use of white space are not simply a matter of style, but also have a significant impact on the accessibility of our code in practice. For example, I am dyslexic and the when multi-line helps to reduce the amount of effort I need to scan, read, and understand a code segment. If my understanding of how folks minds work that do not have to compensate, there is still extra effort needed when there is less use of white-space and indentation, but it is significantly less. It can be passed right by where as its a little tiny scream in my mind every time I hit something making the code harder to process. Totally support the idea that that is simply not a feature that is supported, that is a maintainers choice, but there are few things in this world that are a universal matter of preference. Someone will always need to compensate. |
|
@Vadorequest Well, how about the fact that you stop blaming us for all not solved problems, and you start helping us? How about a couple PRs? It’s easy to say that nobody want to solve issues, and it’s hard to find the best solutions and maintain a high-quality architecture. You have the right to fork and do whatever you want. I would like to add to some words that instead of solving problems, we often have to spend a lot of time on such answers. Do you think adding new options will solve the problems? No, it will only increase them. By adding one, tomorrow developers will demand from us 10 options. And what will it lead to? You yourself will open the issue again, but will blame us again. We are not a closed community, we are OSS and we are waiting and grateful for any help. Solving problems in your own hands. |
Please open a new issue, your request is beyond the scope of this discussion. One must distinguish between desires/preferences and actual problems. |
|
🍿 |
|
@evilebottnawi I'm sorry, but I believe you misunderstood my intents here. I'm not blaming anyone for "not solved problems". I'm just trying to clarify the situation so that people don't misunderstand Prettier direction and intents. I honestly don't see how I could help either. There is no point opening PR you don't intend to merge, and I don't intend to spend time on PR that won't be merged. That's why I first wanted to clarify the vision the core teams holds about Prettier's future. (motivations) I know it's hard, I'm also an OSS contributor/lead on a few minor projects. I'm not here blaming anyone about things not being done, but rather trying to understand what should be done. I don't see any easy solution either to the underlying issue. I don't think the current situation is good, it feels like Prettier is unsure about what to do, by allowing PRs like #6644 (and all other similar PR/issues) but not merging/closing them. This makes people waste their time for no result, and will eventually exhaust your contributors/moderators. Please correct me if my understandings are wrong. |
|
@Vadorequest Tell me what is the real problem with the specified issue? You prefer write code with this style? I prefer with other style. And we will have more 10 people who also write it differently. Who is right? Or maybe we need to support all possible styles? So what's the point then of a universal formatter? Should we turn back 10 years and see horribly formatted code with different styles again? We all have to sacrifice something to benefit others. And it's not just about programming. If you think that we decide how it will look, then you are mistaken. This is a huge work done over many years, feedback, discussions, and much more. I'm afraid you do not quite understand the philosophy of prettier. If you think the prettier is so bad, just don’t use it. An ideal formatter should not have options, you should write code, and not think about spaces and newlines. You constantly claim what makes the code less readable/maintainable/quality (don't understand And the last question - How would you fix these problems?. |
The problem is to allow and encourage contributors to work on PR that won't be merged. The problem is that core maintainers were unsure about what to do for #3101, I'm not saying you should add tons of options, nor support all possible combinations. I believe we're all experienced enough to understand the side effects, and that it's clearly not the way to go (and it's against the philosophy that drives you). A plugin system was mentioned above by several contributors (#8507 (comment)), but was not given any follow up. It may indeed be the way to go? I know too little of Prettier internals to feel like I can tell what would be the best option, but a plugin system that make the Prettier's base flexible (customizable/extendable/etc.), where the work of maintaining a more complicated set of options that may be specific to a language/framework/code style would be handled by the maintainers of such plugins makes sense to me. I'd love to know what you think about that. |
|
Plugin system is still on roadmap, but we don't have good ideas how implements this, there is a lot of ideas, but they are all far from even becoming stable. We don’t refuse plugin system, we just don’t know how to make them, if you have ideas and solutions, we will listen to them with pleasure. I want to close this problem because it is like holy war. Discussion of problems should take place in their branches. Here we still will not solve anything. Let's continue discussion in the plugin system issue. I will help you. /cc @simonhaenisch Please open an new issue, we should consider how we can improve our output for people with dyslexic. Closed in favor #4424 |
Closed in favor #4424
There are many open issues about big disagreements regarding how code should be formatted. Those issues go back up to 2017, which is a really, really long way, and still aren't answered, mostly because it doesn't align with the current Prettier's vision.
(very) Short list:
Keep multi-line formatting for destructuring assignment #2550 (2017!)
I recently vented out on my frustration after failing at configuring Prettier the way I want and establish a fixed formatting rules in my company. Since then, I've cooled down and want to take a step back.
There are many developers who are trying out Prettier and leaving it because it doesn't do a good-enough job, and provides no work around. That's not great to see.
Don't get me wrong, having a limited subset of options is a great purpose and vision. But it falls short when such formatting is applied without any possible work around and creates daily frustration for thousands of developers. It's also the case when changes in behaviour are made without providing the ability to go back to the former formatting way.
After reading through a lot of the issues and PR, the issue that comes back is always the same: "Pretty" code is not as important as "readable" code.
The above issues exist because:
The goal of this RFC is to talk about those thing in a more general way, and decide what Prettier should do, what direction it should take.
This comment is great because it explains the root issue above mentioned: Developers need Prettier to help them with those things (code review, readability), and currently, this isn't really the goal of Prettier. It does help in general, but it's not Prettier's vision and that's why there has been discussions for years about what Prettier should and shouldn't do.
So, what about adapting the current vision/mission of Prettier and see if it could change from "An opinionated code formatter" to "An opinionated code formatter meant to improve code quality/readability"?
With such a refined vision, decisions would be much easier to take, regarding:
I hope we can have a discussion to see what the Prettier community and the core maintainers think about that.
The text was updated successfully, but these errors were encountered: