-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
Remove whitespace generation #5833
Conversation
@@ -1,11 +1,9 @@ | |||
var test = { | |||
/** | |||
* Before bracket init | |||
*/ | |||
["a"]: "1", | |||
*/["a"]: "1", |
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.
Seems like a bad case here.
function test() {} | ||
|
||
// Copyright (C) 2012 Yusuke Suzuki <utatane.tea@gmail.com> | ||
function test() {} // Copyright (C) 2012 Yusuke Suzuki <utatane.tea@gmail.com> |
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.
Hmm, also an unfortunate case.
Love this PR, anything to simplify codegen is a plus in my book. I'd vote for including newlines after all block comments to make some of these examples nicer, and maybe to include a newline after all declaration statements? |
Yes will look into this, what I also noticed is that function a () {
}; gets reprinted as function a() {
}
; But this is because of the |
Codecov Report
@@ Coverage Diff @@
## 7.0 #5833 +/- ##
==========================================
- Coverage 85.25% 85.19% -0.07%
==========================================
Files 284 283 -1
Lines 9963 9921 -42
Branches 2781 2765 -16
==========================================
- Hits 8494 8452 -42
+ Misses 969 967 -2
- Partials 500 502 +2
Continue to review full report at Codecov.
|
Okay I change the generation now:
I'm not sure how I could add a newline after every declaration. I also made two commits. One with the code changes and one with the test fixes. |
var a: { y: string, (): number, (x: string): string, }; | ||
var a: { <T>(x: T): number }; | ||
interface A { (): number }; | ||
var a: { (): number |
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.
Weird asymmetry on these objects. I think if the closing bracket is on its own line, the opening one should be too.
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.
Fixed
interface A { foo: () => number }; | ||
interface Dictionary { length: number, [index: string]: string, }; | ||
interface A {} | ||
; |
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.
Are these actually parsed as EmptyStatement
nodes, or is the semicolon being printed weirdly.
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.
Not sure about this and how to approach. There is always an EmptyStatement generated after declarations with semicolon, and I'm not sure how we could ignore it if possible.
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.
Looking at the AST from Flow itself, the semicolons are not in the grammar for interface declarations, which means the current behavior of parsing them as EmptyStatement nodes is correct. We should probably just remove the semicolons from the actual.js
files, but I understand if you don't want to for now.
comment.type === "CommentBlock" && | ||
( | ||
(!comment.value.startsWith(":") && | ||
!comment.value.startsWith("flow-include")) || |
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.
Do we have any tests for this? Does Flow actually require these to be on the same line, or is this just for making it nicer to read? I don't love having a special case like this.
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 tested and they don't need to be on the same line. Will remove
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.
Should I leave the case that only block comments with newlines inside them get newlines around them? Or add newlines around to all block comments?
So that inline block comments stay inline? like function a(a/*, 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.
I removed it now, all BlockComments have newline around them now.
Are we removing end of file newlines now? |
Not sure about the actual output, in the fixture runner they are always trimmed. I will check |
@hzoo It seems to me we are always removing whitespaces at the end already here: https://github.com/babel/babel/blob/7.0/packages/babel-generator/src/buffer.js#L45 Although we might remove the |
Could we do this for code generation - don't worry too much about styling while generating code, but then pipe it through a linter's autofix for style consistency in the generated code? That should free us from worrying about special cases like switch-case and empty statement. Pros:
Cons:
|
The purpose was to make babel-generator faster so having to use another tool would go against this idea especially since it's easier to just encode the logic in the printer itself rather than in an autofixer. And if we were going to do that I would just use prettier as the printer anyway (which is much slower than hardcoding something simple)? I think we just want it to look presentable but focus on speed. Again it's generated output not the source code (why we removed the options for quotes). |
Let me know if I should change more in this PR. |
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.
@danez I'm totally good with this, I would just be more generous with adding newlines/whitespace (less checks to see if it's necessary or not) and then maybe figure out the ;
thing so tests look more "normal" later
return { | ||
before: node.consequent.length || parent.cases[0] === node, | ||
after: !node.consequent.length && parent.cases[parent.cases.length - 1] === node, |
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 doesn't make sense.
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.
Why not? It only covers the case of empty last case
switch() {
default:
}
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.
Oh, i read this as two !node.consequent.length && last(node.consequent)
. Never mind.
if ( | ||
parent.callProperties[0] === node && | ||
(!parent.properties || !parent.properties.length) | ||
) { |
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.
Negative indent.
Changes to printing: * Add newline after last empty SwitchCase * Add newlines around block comments if they are non-flow comments or contain newlines
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 work on fixing the semis in the test fixtures
Alright then! |
Thanks for taking care. |
For what it's worth, you can still retain newlines when printing a statement list by comparing the |
This removes the whitespace generation and the generator would now simply print everything according to the default settings and not based on the AST tokens.
By removing this babel can use babylon without tokens, which brings a performance boost in babylon.
This change on it's own doesn't change the performance much. I tried printing react a 100 times with (14.8s) and without (15.0s) this change and it is neglectable, but at least not bad.
I removed all expected files and regenerated them.