-
Notifications
You must be signed in to change notification settings - Fork 657
feat(rome_js_formatter): elide quotes in object/class members #2536
Conversation
} | ||
|
||
type B = { "string": "B" }; | ||
type B = { string: "B" }; |
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 matches prettier's output
Parser conformance results on ubuntu-latestjs/262
jsx/babel
symbols/microsoft
|
Test result | main count |
This PR count | Difference |
---|---|---|---|
Total | 588 | 588 | 0 |
Passed | 519 | 519 | 0 |
Failed | 69 | 69 | 0 |
Panics | 0 | 0 | 0 |
Coverage | 88.27% | 88.27% | 0.00% |
ts/microsoft
Test result | main count |
This PR count | Difference |
---|---|---|---|
Total | 16257 | 16257 | 0 |
Passed | 12391 | 12391 | 0 |
Failed | 3866 | 3866 | 0 |
Panics | 0 | 0 | 0 |
Coverage | 76.22% | 76.22% | 0.00% |
Deploying with Cloudflare Pages
|
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.
It turns out that prettier applies the same logic to both JS and TS.
This isn't the case for all number
text_to_check.chars().enumerate().all(|(index, c)| { | ||
// Members that starts with numbers in their name are not valid syntax, | ||
// hence we can't elide the quotes | ||
if index == 0 && c.is_numeric() { |
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.
I just checked this again and we forgot that we're talking about members, not identifiers.
A all digits string member can be turned into a number literal that.
{
"123": true,
// same as
123: true
}
However, Prettier doesn't unquote all number members in TypeScript.
So the rule must support:
- string forming a valid identifier -> print as identifier
- string forming a valid number -> print as number literal (only for JS)
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.
That is true, but prettier doesn't seem to remove the quotes from numeric-like members (that can be valid members): playground
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.
You need to change the parser to babel
.
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 should be flagged now, I added a new test that should cover the case
Could you please share some cases that I might have missed, please? I couldn't find one |
Sorry, I didn't intend to submit that comment. I first started this comment before I then wrote the more detailed comment in |
text_to_check.chars().enumerate().all(|(index, c)| { | ||
// Members that starts with numbers in their name are not valid syntax, | ||
// hence we can't elide the quotes | ||
if index == 0 && c.is_numeric() { |
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.
You need to change the parser to babel
.
PR on hold as at the moment the formatter doesn't have the understanding if it's parsing a TS file or a JS file. In order to give this information to the formatter, we have to extract it from the |
ee6d28e
to
9872483
Compare
9872483
to
250a139
Compare
250a139
to
a79ceef
Compare
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.
I'll need to review the rest tomorrow. This is some sophisticated stuff that my brain isn't capable of handling at this time of a day :D
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.
Looks good. One thing that I'm wondering is if it would be better to have small helper functions for the string cleaning but then have different
FormatLiteralMemberName
FormatDirectiveLiteral
- ...
Functions that call into this helpers. It could help to remove some branching and may help to split this code into some smaller files.
I'm considering this because it feels like it's becoming this one string manipulation that is able to handle ALL cases which makes it harder to reason about how the code works (for a specific case)
crates/rome_js_formatter/src/js/assignments/object_assignment_pattern_property.rs
Outdated
Show resolved
Hide resolved
crates/rome_js_formatter/src/js/bindings/object_binding_pattern_property.rs
Outdated
Show resolved
Hide resolved
crates/rome_js_formatter/src/js/classes/constructor_class_member.rs
Outdated
Show resolved
Hide resolved
74dc656
to
125ad84
Compare
Makes sense. Allow me to address these concerns in the next PR. The works on these PR are not finished yet. The cases are not over unfortunately (we still have the escaping of other chars) . At this point it might make more sense to also have a small module for each case (directive, member, literal string) |
I'm not opposed to it. Is this something you're planning to work on soon? |
Yes, it's in my bucket list :) |
Summary
This PR closes #2405
I cherry-picked the commits of the previous PR that introduced these changes in the first place, then applied the logic for checking the source type.
Test Plan
I created new test cases.
Unfortunately it's not easy to compare it with Prettier output, that's why I suggest to compare their playground with our snapshots.