-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
[RFC] Keep expanded objects expanded #495
Conversation
@@ -73,6 +73,8 @@ function utf16Length(str, pos) { | |||
exports[`test keys.js 1`] = ` | |||
"({\'この事はつもり素晴らしいことさ\': \'35jL9V\'}) | |||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |||
({ \"この事はつもり素晴らしいことさ\": \"35jL9V\" }); | |||
({ | |||
\"この事はつもり素晴らしいことさ\": \"35jL9V\" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bug in the flow parser, it incorrectly computes the length of the string with unicode characters inside.
A lot of the tests changes are good example why I'm hesitant to do this. We should help the user simplify the code and a ton of those changes look like regressions to me. This seems like a place ripe for disagreements on a team and "nits" to start coming through to tell them to put an object on a single line because it's so small and fits inside the function call, etc. This might be one of those things where I'd rather wait a while before doing, because we can't remove it after landing. I'd like to hear more from users about if this is an actual problem (only heard from a few that do, but many others may not want it) |
Yeah, I'm not really sure about it either. I'll keep sending various ideas to fix the problem :) |
This looks much cleaner to me. When this kind of code evolves people end up adding more properties and you expand anyway at some point. Might as well do this right away. For types, you can always hoist them up for readability. |
Hmm this one feels a little concerning to me... Agreed it may be worth sitting on a bit... |
Some random thoughts on the subject: The first attempts at solving the nits/formatting problem look like The second iteration is something like refmt where you reformat all the code with no exceptions. This is great and consistent but it is very inflexible. Developers want some control over how the code is formatted. #7 is an example that exploits the fact that empty lines are added before comments, so the person puts some random comments in order to make the code breathe. I think that in order to succeed we need a middle ground. Where most of the code is automatically formatted but the user still has some control for cases where it cannot be always be automatically formatted in a reasonable way. We've done this successfully so far for empty lines, and objects may be a place where this would work as well. |
And, if we remove all the nits except for ones on objects, I still think the project would be super successful :) |
Alright. I don't have strong enough objections to hold this back. I'm fine moving forward with it. I don't want this to open the doors for other customizations based on input code; we should really try to restrict it. But I don't see this doing a lot of harm. |
Let's try this and revert it if it leads to people abusing it :) |
e2b5dc6
to
1237be4
Compare
Another attempt at solving the issue where objects are not expanded the way people expect. If there's any new line in the original source, it's going to expand it. This gives more control to the user in how the objects should be formatted. Fixes prettier#74
1237be4
to
e2ff4dd
Compare
Another attempt at solving the issue where objects are not expanded the way people expect. If there's any new line in the original source, it's going to expand it. This gives more control to the user in how the objects should be formatted.
Fixes #74