This version is covered by your current version range and after updating it in your project the build failed.
As prettier is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.
I recommend you give this issue a high priority. I’m sure you can resolve this :muscle:
Status Details
- ❌ **continuous-integration/travis-ci/push** The Travis CI build failed [Details](https://travis-ci.org/captbaritone/raven-for-redux/builds/238819628?utm_source=github_status&utm_medium=notification)
Release Notes1.4.0: TypeScript and CSS support
TypeScript Support
This is the most requested feature for prettier. With 1.4.0, you can now use prettier to format your .ts and .tsx files!
The way prettier works is by using those project to generate an AST representation of the code and print it. Both babylon (the parser that powers babel) and flow are producing an AST approximately following the estree format for the JavaScript parts and then have special nodes for Flow-specific ones.
TypeScript, the same way as Flow, introduces special nodes for the syntax it introduces. Unfortunately, it doesn't follow the estree format for the rest of the JavaScript language. This puts us in a rough spot with prettier as we would have to essentially completely fork it in order to print TypeScript.
This incompatibility with the AST is not a new problem and another project struggled with it: ESLint. Because the AST is different, none of the ESLint rules are working. Fortunately for us, @JamesHenry and @soda0289 wrote a project called typescript-eslint-parser which takes a TypeScript AST and convert it to an estree one, just what we need for prettier!
After that project got setup inside of prettier, @azz, @despairblue and @Pajn implemented all the TypeScript-specific nodes and ensured that the 13k tests of the TypeScript test suite are correctly passing. This was a huge undertaking and it is finally ready to be used :)
We tested prettier on the biggest TypeScript projects we could find on GitHub to ensure that it prints correct code. We haven't spent a lot of time trying to optimize the way code is formatted yet, so if you see something strange, please raise an issue!
CSS, Less and SCSS Support
While TypeScript is the most requested feature from open source, CSS is the biggest one from Facebook engineers. Once you are used to pretty print your code in one language, you want to do it everywhere!
Unfortunately, postcss right now doesn't parse Sass nor Stylus. We'd be happy to support them if someone is willing to do the work of printing them.
Note that prettier is currently just formatting the code, it does not respect any options yet such as singleQuote nor is doing any color or number normalization like we do for JavaScript.
Editor Integration
The first phase of the project was to make prettier output correct and good looking code. Now that it's in a good shape, we can spend time on making the integrations better. We just introduced support for two great features: maintain cursor position and being able to format a range instead of the entire file.
Note that we just landed the support inside of prettier itself, none of the editor integrations are using it yet. Also, we haven't really tried them out in practice so we're likely going to have to fix rough edges with them!
Right now, we let editors figure out where the cursor should be, which they do an okay job at. But since we are printing the code, we can give the correct position!
Add --range-start/end options to format only parts of the input (#1609) by @josephfrazier
This one is a very often requested feature. Right now prettier only formats the entire file. Now it is possible to format a range.
The way it works is by going up through the AST in order to find the closest statement. This way you don't need to select exactly the right range that is valid. You can just drag in the rough place where the code you want to reformat it, and it's going to!
Adding filepath option in order to enable filetype inference (#1835) by @mitermayer
Since we are now formatting CSS and TypeScript, it is not convenient to have to specify the parser for every file. You can now pass the filepath of the file you are working on and prettier will read the extension and figure out the right parser to use.
The biggest remaining issue that people have with prettier when printing JSX is when it is used when printing text. The behavior of prettier used to add an ugly {" "} before and if a line was too long, just leave it alone. Now we treat each word as a token and are able to make it flow correctly.
This is an awesome piece of work by @karl as not only did he implement the feature, but also introduced a new primitive inside of prettier in order to print a sequence of elements and break as soon as one hits the edge.
// Before<div>
Please state your
{""}
<b>name</b>
{""}
and
{""}
<b>occupation</b>
{""}
for the board of directors.
</div>// After<div>
Please state your <b>name</b> and <b>occupation</b>for the board of
directors.
</div>
Remove parenthesis for JSX inside of arrow functions (#1733) by @xixixao
People writing functional components are going to be happy about this one. We no longer put parens for arrow functions that return JSX.
// Beforeconstrender1= ({ styles }) => (
<div style={styles}>
Keep the wrapping parens. Put each key on its own line.
</div>
);
// Afterconstrender1= ({ styles }) =><div style={styles}>
Keep the wrapping parens. Put each key on its own line.
</div>;
Template literal printing has always caused prettier a lot of difficulties. With 1.3.0 we massively improved the situation and with this release, I believe that we handle all the common situations in a good way.
In order to workaround issues, we added an utility that removes empty lines from the output, but it yielded some really weird results sometimes, this is now gone. Another tweak we've done is instead of indenting when ${ starts, we indent where the line that contains ${ starts.
Let us know if you still have issues with how template literals output after this release!
Use the same breaking rules for assignment and object values (#1721)
We have a lot of fine-tuned logic for how to break things after assignment (eg a = ...). We are now using the same one for object values. This should help for multi-line boolean logic, or big conditionals. This is also a good example of how we can create a consistent printer.
There's been a steady stream of people complaining about the way it was rendered and was put on the list of things that are probably hard to do, will check later. It turned out to be super easy, so here you go!
// Before
type Foo =Promise<| { ok:true, bar: string, baz: SomeOtherLongType }
| { ok:false, bar: SomeOtherLongType }
>;
// After
type Foo =Promise<
{ ok:true, bar: string, baz: SomeOtherLongType } |
{ ok:false, bar: SomeOtherLongType }
>;
Do not put parens for single argument with end of line comment (#1518)
The detection code for whether an arrow function should be written without parenthesis just checked if there was a comment, but instead we only want comments that are inline like (/* comment */ num), not end of line comments.
This avoids making it seems like it is indented by 4 characters instead of two. The downside is that if the condition is multi-line it's not going to be properly aligned, but I feel it's a better trade-offs. If you are doing nested ternaries, you usually have small conditions.
We want to inline objects inside of a boolean expression as it looks weird to have { on its own line. But it turns out that it leads to weird behaviors for empty objects. So we keep them on their own line if they are empty.
Remove Parens from SequenceExpressions in ForStatements (#1597) by @k15a
It is common to assign multiple values inside of a for loop, now we don't add parenthesis anymore.
// Beforefor ((i =0), (len =arr.length); i < len; i++) {
// Afterfor (i =0, len =arr.length; i < len; i++) {
Do not inline arrow when argument has a leading comment (#1660)
If you put block comments inside of arrow functions, we no longer mess everything up!
// Beforeexportconstbem=block=>/** * @param{String}[element] - the BEM Element within that block; if undefined, selects the block itself. */element=>/** * @param{?String}[modifier] - the BEM Modifier for the Block or Element; if undefined, selects the Block or Element unmodified. */modifier=>// Afterexportconstbem=block=>/** * @param{String}[element] - the BEM Element within that block; if undefined, selects the block itself. */element=>/** * @param{?String}[modifier] - the BEM Modifier for the Block or Element; if undefined, selects the Block or Element unmodified. */modifier=>
We handled some placements before and kept adding places where they could appear, now we switch to a more general approach. Hopefully those issues shouldn't crop up in the future anymore.
// BeforeconstconfigModel=this.baseConfigurationService.getCache().consolidated// global/default values (do NOT modify)
.merge(this.cachedWorkspaceConfig);
// AfterconstconfigModel=this.baseConfigurationService
.getCache()
.consolidated// global/default values (do NOT modify)
.merge(this.cachedWorkspaceConfig);
Put JSX comments inside of the parenthesis (#1712)
This mostly affects Facebook engineers where we automatically add $FlowFixMe when pushing a new version of flow. Now it no longer messes up those comments.
Force \n for multiple variable declarations (#1723)
This one has been very often requested. We used to only break multiple variable declarations if the line was > 80 columns. Now we do it regardless if there's at least one with an assignment.
The expanded version of flow union looks good when they are many objects but if it's used for nullability, the it looks very weird. We're now inlining | null and | void.
The same way we don't break long require calls, we no longer break import statements if there is only a single thing being imported.
// Beforeimport somethingSuperLongsomethingSuperLong
from "somethingSuperLongsomethingSuperLongsomethingSuperLong";
// AfterimportsomethingSuperLongsomethingSuperLongfrom"somethingSuperLongsomethingSuperLongsomethingSuperLong";
Add the ability for SequenceExpression to break (#1749)
Did you know that if none of your code were statements, you could use () instead of {} and , instead of ;? Now you do. Some people exploit this fact when returning things from arrow functions. This is not recommended but it's easy to support in prettier so might as well ¯_(ツ)_/¯
We used to find where to put comments by traversing the AST using the definition from ast-types. This occasionally caused issues when some field wasn't declared, we wouldn't find the node and either print comments in an incorrect location or throw an error. It turns out that we don't need to keep this mapping and can just traverse the objects and if a node has a type field, then it's a node.
// BeforeError: did not recognize object of type "ObjectTypeSpreadProperty"// After
type X= {...Y/**/};
type X= {/**/...Y};
If you were adding invisible characters inside of JSX text, we would replace them by regular spaces. I don't know why anyone would ever want to do that, but now we print it back as is!
We used to have some pretty complicated (and not working well) code to handle comments inside of template literals. We introduced a really nice solution for JSX {} expressions. The idea is to introduce a boundary before the end of the } and if we still have unprinted comments, then flush them all at once, put a \n and print the }. We are now using this logic for template literals :)
We don't have an automated way to put parenthesis, we instead specify all the possible combinations of nodes and when they should or shouldn't have parenthesis. So there's likely a long tail of unusual combinations that are still remaining. In this case, we made await handling a lot more robust by both adding parenthesis where they are needed and removing them when they are not.
We want prettier to be able to parse all the JavaScript out there. For babylon parser, we have to chose whether a file is using strict mode or not. We opted in to use strict mode by default as most files parse that way. But if you have octal literals like 0775, it would not even parse. Now if it fails to parse in strict mode, we're going to try again in non-strict. We also allow return outside of a function as it's valid in node files.
// BeforeSyntaxError// Afterreturn0775;
CLI
Allow --write to be used with --list-different (#1633)
This is useful to combine the two if you are writing a commit hook to tell the user what actually changed in a single command.
Ignore node_modules when running prettier from CLI (#1683) by @thymikee
It's very easy to run prettier over the node_modules/ folder by mistake which is something you almost never want to. So now we disable it by default and add a --with-node-modules option if you really want to.
We enabled the option to go through .dotfiles in the glob parsing library we are using. This means that writing * will now catch .eslintrc.
Not sure how things should work exactly?
There is a collection of [frequently asked questions](https://greenkeeper.io/faq.html) and of course you may always [ask my humans](https://github.com/greenkeeperio/greenkeeper/issues/new).
Version 1.4.0 of prettier just got published.
This version is covered by your current version range and after updating it in your project the build failed.
As prettier is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.
I recommend you give this issue a high priority. I’m sure you can resolve this :muscle:
Status Details
- ❌ **continuous-integration/travis-ci/push** The Travis CI build failed [Details](https://travis-ci.org/captbaritone/raven-for-redux/builds/238819628?utm_source=github_status&utm_medium=notification)Release Notes
1.4.0: TypeScript and CSS supportTypeScript Support
This is the most requested feature for prettier. With 1.4.0, you can now use prettier to format your
.ts
and.tsx
files!The way prettier works is by using those project to generate an AST representation of the code and print it. Both babylon (the parser that powers babel) and flow are producing an AST approximately following the estree format for the JavaScript parts and then have special nodes for Flow-specific ones.
TypeScript, the same way as Flow, introduces special nodes for the syntax it introduces. Unfortunately, it doesn't follow the estree format for the rest of the JavaScript language. This puts us in a rough spot with prettier as we would have to essentially completely fork it in order to print TypeScript.
This incompatibility with the AST is not a new problem and another project struggled with it: ESLint. Because the AST is different, none of the ESLint rules are working. Fortunately for us, @JamesHenry and @soda0289 wrote a project called typescript-eslint-parser which takes a TypeScript AST and convert it to an estree one, just what we need for prettier!
After that project got setup inside of prettier, @azz, @despairblue and @Pajn implemented all the TypeScript-specific nodes and ensured that the 13k tests of the TypeScript test suite are correctly passing. This was a huge undertaking and it is finally ready to be used :)
We tested prettier on the biggest TypeScript projects we could find on GitHub to ensure that it prints correct code. We haven't spent a lot of time trying to optimize the way code is formatted yet, so if you see something strange, please raise an issue!
CSS, Less and SCSS Support
While TypeScript is the most requested feature from open source, CSS is the biggest one from Facebook engineers. Once you are used to pretty print your code in one language, you want to do it everywhere!
It turns out that CSS is a much smaller language than JavaScript and supporting it only took a few days. We are using postcss by @ai as the underlying parser which is able to parse CSS, Less and SCSS. We also depend on postcss-values-parser, postcss-selector-parser by @ben-eb postcss-media-query-parser by @dryoma.
Unfortunately, postcss right now doesn't parse Sass nor Stylus. We'd be happy to support them if someone is willing to do the work of printing them.
Note that prettier is currently just formatting the code, it does not respect any options yet such as
singleQuote
nor is doing any color or number normalization like we do for JavaScript.Editor Integration
The first phase of the project was to make prettier output correct and good looking code. Now that it's in a good shape, we can spend time on making the integrations better. We just introduced support for two great features: maintain cursor position and being able to format a range instead of the entire file.
Note that we just landed the support inside of prettier itself, none of the editor integrations are using it yet. Also, we haven't really tried them out in practice so we're likely going to have to fix rough edges with them!
Add
cursorOffset
option for cursor translation (#1637) by @josephfrazierRight now, we let editors figure out where the cursor should be, which they do an okay job at. But since we are printing the code, we can give the correct position!
Add
--range-start/end
options to format only parts of the input (#1609) by @josephfrazierThis one is a very often requested feature. Right now prettier only formats the entire file. Now it is possible to format a range.
The way it works is by going up through the AST in order to find the closest statement. This way you don't need to select exactly the right range that is valid. You can just drag in the rough place where the code you want to reformat it, and it's going to!
Adding filepath option in order to enable filetype inference (#1835) by @mitermayer
Since we are now formatting CSS and TypeScript, it is not convenient to have to specify the parser for every file. You can now pass the filepath of the file you are working on and prettier will read the extension and figure out the right parser to use.
Highlights
Wrap text content inside of JSX (#1120, #1671, #1827, #1829) by @karl
The biggest remaining issue that people have with prettier when printing JSX is when it is used when printing text. The behavior of prettier used to add an ugly
{" "}
before and if a line was too long, just leave it alone. Now we treat each word as a token and are able to make it flow correctly.This is an awesome piece of work by @karl as not only did he implement the feature, but also introduced a new primitive inside of prettier in order to print a sequence of elements and break as soon as one hits the edge.
Remove parenthesis for JSX inside of arrow functions (#1733) by @xixixao
People writing functional components are going to be happy about this one. We no longer put parens for arrow functions that return JSX.
Improve template literal printing (#1664, #1714) by @josephfrazier
Template literal printing has always caused prettier a lot of difficulties. With 1.3.0 we massively improved the situation and with this release, I believe that we handle all the common situations in a good way.
In order to workaround issues, we added an utility that removes empty lines from the output, but it yielded some really weird results sometimes, this is now gone. Another tweak we've done is instead of indenting when
${
starts, we indent where the line that contains${
starts.Let us know if you still have issues with how template literals output after this release!
Use the same breaking rules for assignment and object values (#1721)
We have a lot of fine-tuned logic for how to break things after assignment (eg
a = ...
). We are now using the same one for object values. This should help for multi-line boolean logic, or big conditionals. This is also a good example of how we can create a consistent printer.Indent conditions inside of !() (#1731)
There's been a steady stream of people complaining about the way it was rendered and was put on the list of things that are probably hard to do, will check later. It turned out to be super easy, so here you go!
Formatting Fixes
Put loop bodies on the same line when possible (#1498)
We were already doing this for if statements, we should be consistent and also do it for loops.
Fix empty line with flow union (#1511) by @existentialism
We shouldn't indent things twice ;)
Do not put parens for single argument with end of line comment (#1518)
The detection code for whether an arrow function should be written without parenthesis just checked if there was a comment, but instead we only want comments that are inline like
(/* comment */ num)
, not end of line comments.Do not indent nested ternaries (#1822)
This avoids making it seems like it is indented by 4 characters instead of two. The downside is that if the condition is multi-line it's not going to be properly aligned, but I feel it's a better trade-offs. If you are doing nested ternaries, you usually have small conditions.
Inline chained conditionals inside of jsx attribute (#1519)
We don't need to use the indentation to disambiguate another block as nothing can come after.
Unescape unnecessarily escaped characters in strings (#1575) by @josephfrazier
We are already trying to cleanup strings in various ways, this is another small addition that's going to remove
\
that are not needed.Fix boolean for empty objects (#1590) by @dmitrika
We want to inline objects inside of a boolean expression as it looks weird to have
{
on its own line. But it turns out that it leads to weird behaviors for empty objects. So we keep them on their own line if they are empty.Remove Parens from SequenceExpressions in ForStatements (#1597) by @k15a
It is common to assign multiple values inside of a for loop, now we don't add parenthesis anymore.
Do not inline arrow when argument has a leading comment (#1660)
If you put block comments inside of arrow functions, we no longer mess everything up!
Fix last comments of imports (#1677)
Another place where we have to do special logic for comments!
Handle comments in member chain (#1686, #1691)
We handled some placements before and kept adding places where they could appear, now we switch to a more general approach. Hopefully those issues shouldn't crop up in the future anymore.
Use expandLast for nested arrow functions (#1720)
Put JSX comments inside of the parenthesis (#1712)
This mostly affects Facebook engineers where we automatically add
$FlowFixMe
when pushing a new version of flow. Now it no longer messes up those comments.Force \n for multiple variable declarations (#1723)
This one has been very often requested. We used to only break multiple variable declarations if the line was > 80 columns. Now we do it regardless if there's at least one with an assignment.
Inline | null and | void (#1734)
The expanded version of flow union looks good when they are many objects but if it's used for nullability, the it looks very weird. We're now inlining
| null
and| void
.Break on implements instead of extends (#1730)
We no longer break on
extends
. This should make classes with extends that can break look less wonky.Inline single import (#1729)
The same way we don't break long
require
calls, we no longer breakimport
statements if there is only a single thing being imported.Add the ability for SequenceExpression to break (#1749)
Did you know that if none of your code were statements, you could use
()
instead of{}
and,
instead of;
? Now you do. Some people exploit this fact when returning things from arrow functions. This is not recommended but it's easy to support in prettier so might as well ¯_(ツ)_/¯Don't force line break in empty loop bodies (#1815)
Loops with empty body no longer have their
{}
split into two lines.Preserve empty lines between switch cases with comments (#1708)
Correctness
Remove ast-types (#1743, #1744, #1745, #1746, #1747)
We used to find where to put comments by traversing the AST using the definition from ast-types. This occasionally caused issues when some field wasn't declared, we wouldn't find the node and either print comments in an incorrect location or throw an error. It turns out that we don't need to keep this mapping and can just traverse the objects and if a node has a
type
field, then it's a node.Preserve unusual unicode whitespace (#1658, #1165) by @karl and @yamafaktory
If you were adding invisible characters inside of JSX text, we would replace them by regular spaces. I don't know why anyone would ever want to do that, but now we print it back as is!
Don't let trailing template literal comments escape (#1580, #1713, #1598, #1713) by @josephfrazier and @k15a
We used to have some pretty complicated (and not working well) code to handle comments inside of template literals. We introduced a really nice solution for JSX
{}
expressions. The idea is to introduce a boundary before the end of the}
and if we still have unprinted comments, then flush them all at once, put a \n and print the}
. We are now using this logic for template literals :)Parenthesize await correctly (#1513, #1595, #1593) by @bakkot and @existentialism
We don't have an automated way to put parenthesis, we instead specify all the possible combinations of nodes and when they should or shouldn't have parenthesis. So there's likely a long tail of unusual combinations that are still remaining. In this case, we made
await
handling a lot more robust by both adding parenthesis where they are needed and removing them when they are not.Preserve getter/setter info on flow ObjectTypeProperty (#1585) by @josephfrazier
Another long tail option that we haven't got right!
Add parenthesis for single arg types with generics (#1814)
Another case of sneaky parenthesis that we didn't properly add!
Fall back to non-strict mode in babylon (#1587, #1608) by @josephfrazier
We want prettier to be able to parse all the JavaScript out there. For babylon parser, we have to chose whether a file is using strict mode or not. We opted in to use strict mode by default as most files parse that way. But if you have octal literals like
0775
, it would not even parse. Now if it fails to parse in strict mode, we're going to try again in non-strict. We also allowreturn
outside of a function as it's valid in node files.CLI
Allow
--write
to be used with--list-different
(#1633)This is useful to combine the two if you are writing a commit hook to tell the user what actually changed in a single command.
Ignore node_modules when running prettier from CLI (#1683) by @thymikee
It's very easy to run prettier over the
node_modules/
folder by mistake which is something you almost never want to. So now we disable it by default and add a--with-node-modules
option if you really want to.Traverse dot files for glob (#1844) by @jhgg
We enabled the option to go through .dotfiles in the glob parsing library we are using. This means that writing
*
will now catch.eslintrc
.Not sure how things should work exactly?
There is a collection of [frequently asked questions](https://greenkeeper.io/faq.html) and of course you may always [ask my humans](https://github.com/greenkeeperio/greenkeeper/issues/new).Your Greenkeeper Bot :palm_tree: