* Add new fill primitive and use it to wrap text in JSX
This adds a new `fill` primitive that can be used to fill lines with as much code as possible before moving to a new line with the same indentation.
It is used here layout JSX children. This gives us nicer wrapping for JSX elements containings lots of text interspersed with tags.
* Quick fix for jsx whitespace regressions
* Fix a couple more bugs
* Tidy up the `fill` algorithm
Attempt to make the algorithm a little more regular, and improve the naming of variables to make it a little easier to understand (I hope!).
* Small tidy up of JSX whitespace declarations
* Remove unnecessary code
It turns out that `children` is only used in the case when the element is printed on a single line, in which case all the types of JSX whitespaces behave the same, so we don't need to special case leading/trailing/solitary whitespace.
* A little more tidy up based on PR feedback
* Fix up tests after rebasing
* Make it explicit that we keep multiple consecutive spaces
* Add an explanatory comment
* Fix broken snapshot in master
* Ignore existing commands when deciding whether content will fit when using fill
* Fix a bug where children would get incorrectly filled onto a line
* Tidy up JSX whitespace names
As I was debugging #1248, I found out that the code to fix was actually making things worse. The other two branches are for decorators and deleting some random value of a function. I ran all the tests and the flow object is actually now preserving empty lines and didn't change anything else.
I'd rather remove all those and if something comes up then fix it properly upstream than having those crutches that we don't know why they exist anymore.
I'm unclear whether anyone was ever confused by this but the eslint page is kind of compelling
```js
// The intent is not clear
var x = a => 1 ? 2 : 3;
// Did the author mean this
var x = function (a) { return 1 ? 2 : 3 };
// Or this
var x = a <= 1 ? 2 : 3;
```
Adding a parenthesis makes it valid with `{"allowParens": true}` rule. Note that if this option is not enabled, the code would not pass lint in the first place.
* Extract custom tests from tests/flow/
Approach:
1. Remove all .js files in tests/flow except .snap.js files.
2. Copy over all .js files from tests/ in the flow repo.
3. Go through the diff looking for deletions.
- It was easy to see which deletions were due to changes in the tests
due to updates in the flow repo.
- For the rest of the deletions, I used `git blame` to verify that
they had been added by us since the flow tests were copied over.
This makes tests/flow/ simply a copy of the tests from the flow repo,
making it easier to sync with the upstream flow tests in the future.
* Add a script for syncing the flow tests
* Sync the flow tests
* Verify parsers against same snapshot
- Reworked run_spec, now accepts 3th optional array argument for
additional parsers to verify against
- Merged duplicate run_spec configs
- Removed duplicate snapshot data
* Formatted run_spec.js with prettier
* Fixed node4 incompatibility
We started using the same logic for union and intersection but then added a special case for `a & {}`. It turns out that they should be handled completely differently in practice.
The heuristic i'm using is if you go from object to non-object or vis-versa, then inline, otherwise go to the next line and indent (like &&).
Fixes#864Fixes#1017
* Revert "Remove mutation in `printBinaryishExpressions` (#1067)"
This reverts commit e7312ad7b2.
* Revert "Make it clear what parser was used in each snapshot (#1068)"
This reverts commit 4f7ae4815b.
Right now it's only doing one test for begin/end, but in the issue #1037, we have two nodes that have the same start but different end. The current implementation incorrectly sorts them and the identifier ends up being before the container and therefore the comment search doesn't recurse into it.
Fixes#1037
While looking at an instability on the React codebase ( ba1299acc2 (diff-2550aa3d377452ae29361f5e53c51c10) ), I realized that we don't let them break which makes the code look weird.
So I added the ability for them to break :)
* Group first arg for inline functions
* Group first arg. Unless there are comments.
* Group first arg. Allow second arg to be empty object/array.
This implementation has a side effect of disallowing empty objects/arrays in the should group last arg heuristic.
* Implement checking for not printing the parens in this case.
* Add test case.
* Remove parent type checking.
* Fix test accordingly.
* Refactor to a better heuristic.
* Add new test cases.
* Fix implementation.
* Fix unnecessary function call.
* Add new test cases 🚀.
* Use isObjectTypePropertyAFunction and create isTypeAnnotationAFunction.
* Add missing space.
* Add new test cases.
* Implement new logic for wrapping binary op in arrowFunctionExpression.
* Add new test cases.
* Reuse new helper function in order to fix#917.
* Add new test case.
* Extend heuristic to dive deeper into mixed types.
* Add new test.
* Enhance logic to cover more cases.
* Add new test cases.
* Disable Flow as it gets BindExpression as an unexpected token.
* Simplify getCombinedDeepest function.
* Add missing case.
* Extract all conditions in switch cases to one top level condition.
* Refactor implementation to make it cleaner and also handle ExpressionStatement.
* Update related test cases.
* Add new test case.
* Make condition less expensive.
* Clean up unecessary conditions, simplify condition involving startsWithOpenCurlyBrace.
* Update and add new test cases for better coverage.
* Remove unecessary condition, refactor canBeFirstInStatement to drop some useless parens.
* Update test cases accordingly 🚀.
* Add new handleOnlyComments function.
* Update tests.
* Update test as the printer forces a trailing newline if there were any contents.
* Implement a different heuristic.
* Update tests.
* Add directives checking in handleOnlyComments function.
* Add directives checking in handleOnlyComments function (amend to retrigger CI).
* Remove duplicate.
This is a leftover from the recast prototype, it hasn't been touched since then. I have never seen anyone not put the label on the same line.
Fixes#859
This is a neat trick from the React codebase. It helps highlight the fact that this is an assignment and not a comparison which is subtle to realize.
Fixes#861
This has come up a couple times on the issue tracker on the react-native-web discussion about Twitter internals. It seems like there's a concensus that people don't break long require calls and they'd rather have it go > 80 columns.
Fixes#303Fixes#752
It seems like precedence for this combination of operators is very unclear to people (myself included) and consistently adding parenthesis there would be good.
Fixes#773
I originally wanted to expand it but I think that it may not be a good decision because it's very common for them to be empty and you want it to take as little space as possible.
I tried to remove all those conditions but I think that there are valid places where we always want to expand like empty if/for/while loops.
Fixes#778
There is an off by one error which made the algorithm not work all the time. In many cases, it actually is the opposite, so whenever you save, it adds/removes that line. I noticed it during the --debug-check run on our codebase but didn't investigate.
Fixes#723
This has come up many times in the past and while going through the fb codebase, there are a few instances where we group array elements logically using empty lines and it's a shame that they are gone.
Joseph Frazier