* Print numbers in a uniform way
- Still preserve the radix (binary, octal, hexadecimal or decimal) used
in the original source code.
- Still preserve scientific notation.
- Add 0 to fractions. `.1` -> `0.1`
- Remove trailing dots from integers. `1.` -> `1`
- Always print the radix letters lowercase. `0b`, `0o`, `0x`
- Always print scientific notation lowercase. `1e1`
- Always print hexadecimal digits uppercase. `0x123ABCDEF`
- Remove unneeded plus in scientific notation. `1e+1` -> `1e1`
- Remove unneeded zeroes in scientific notation. `1e-001` -> `1e-1`
- Preserve leading zeroes in non-decimal radix. This can be useful when
working in binary, and having both `0b111000` and `0b000111` for
example.
* Always print numbers lowercase
* Remove trailing dot in scientific notation
* Update snapshots
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
It turns out that in an unlikely turn of event, the inner group can be inline and not print the opening paren but the outer group breaks and outputs the closing paren which generates invalid JavaScript.
I tried removing the group altogether and no tests failed, so I'm assuming the group wasn't needed in the first place. If it was, we should add tests to cover this.
Fixes#501
When reading the Readme file I noticed that the first `foo` method has only 3 args but every other `foo` method has 4. Therefore, I am adding a 4th arg to the first `foo` method for consistency.
* Proper support for dangling comments
In one code path, the dangling comment case is not properly handled. So I added the dangling comment, but it turns out that we only print manually in two node types: Program and BlockStatement. I made the generic printComment function print it everywhere but those two nodes. I tried to get rid of those special cases but unfortunately we need them there otherwise they are not printed at the right place.
Fixes#20
* Output dangling comments in specific places
The logic was already working, it was just special-cased to the first comment of the file! Presumably because the new line detection logic used to be broken ;)
I manually checked the first 10 snapshots and they are all legit, so I assume that all of them are.
Fixes#356
We don't call the generic print on the BinaryExpression itself, so we need to manually print those comments. It's going to be useful for my work on the MemberExpression :)
It's actually not needed to use conditionalGroup as we can use ifBreak for it. I was able to do it just for cleanup and found out that it also fixed two of the bugs we have with comments. That's great :p
Fixes#485Fixes#486
Conditionals are very common in JSX and it is unfortunate that they take up so much vertical space in the current prettier.
This pull request does a few tweaks:
- It hugs ConditionalExpression (ternary) and LogicalExpression (&&) inside of `{}` in a jsx child, not an attribute
- It doesn't output parenthesis if your parent is a LogicalExpression (&&)
Fixes#317
* Add `--help` CLI flag
* Don't pick up unknown CLI options
This prevents people from adding new CLI options in the future, but
forgetting to add it explicitly to minimist, resulting in a false
"Ignored unknown option" warning.
* Add `-h` and `-v` option aliases
It always bugs me when those don't do `--help` and `--version` for no
reason in CLIs.
* Allow `echo 'test' | prettier` without the `--stdin` flag
* Improve CLI error handling and validation
- Handle errors the same way both when using stdin and when using files.
- Print validation errors nicely.
- Validate int options, instead of silently ignoring bad input.
- Warn about unknown parsers, falling back to babylon. If a new parser
is added in the future, this allows graceful degradation for tools
running an older version of prettier. (Just like how unknown options
are warnings instead of errors.)
- Add comments.
* Run prettier on bin/prettier.js
* docs: add related projects
I think it may help adoption of `prettier` if
people don't have to change their entire coding
style all at once. These projects enable that.
* docs: add prettier-with-tabs to related projects
Mobx is the only popular JavaScript library that I know about which uses decorators. They put things on the same line so we should follow their conventions.
The logic implemented here is the following: if there is one decorator, it's on the same line. If there is more than one, they are each on their own line.
Fixes#325
This was introduced by #314 where `line` should have been `softline`. By the way, I was going to propose renaming `line` to `line_or_space` and `softline` to `line_or_nothing` which should make it more explicit what is going on.
Fixes#461
* new_tests
* move_all_clobbered_tests
* remove all the tests that no longer exist
* re-run flow tests
* Move all the flow tests to tests/flow and prettier to tests/
* Move prettier tests to their own folders
* Add jsfmt files
* run prettier snapshot tests
Given the discussion on #296, it seems like there's debate between spaces around `{}` but no one puts spaces around `[]`. So changing the behavior to respect this.
The original intent of it was for `if then else` and `try catch` as they aren't likely to be empty, but it accidentally caught function bodys, which have many valid reasons to be empty. Let's special case those out.
- Introduce findInDocs that avoids some annoying boilerplate when you want to get a value while traversing the docs
- Implement a hasStopped function that stops the traversal when you found the value you needed