-
Notifications
You must be signed in to change notification settings - Fork 2k
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
chore(deps): update dependency prettier to v1.16.1 #2203
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
renovate
bot
requested review from
abernix and
martijnwalraven
as code owners
January 21, 2019 09:38
renovate
bot
added
the
🎄 dependencies
Updates to dependencies, generally automatically managed by Renovate.
label
Jan 21, 2019
renovate
bot
force-pushed
the
renovate/prettier-1.x
branch
from
January 22, 2019 10:32
dbba4ba
to
8add959
Compare
renovate
bot
changed the title
chore(deps): update dependency prettier to v1.16.0
chore(deps): update dependency prettier to v1.16.1
Jan 22, 2019
renovate
bot
force-pushed
the
renovate/prettier-1.x
branch
5 times, most recently
from
January 23, 2019 11:40
bedb444
to
9b9caaf
Compare
renovate
bot
force-pushed
the
renovate/prettier-1.x
branch
from
January 23, 2019 12:34
9b9caaf
to
f30fd6b
Compare
In the constant juggle to appease its ever-changing desires.
PR has been edited👷 This PR has received other commits, so Renovate will stop updating it to avoid conflicts or other problems. If you wish to abandon your changes and have Renovate start over then you can add the label |
abernix
added a commit
that referenced
this pull request
Aug 31, 2019
This change should not stop any developers from using auto code formatting tools (e.g. Prettier, which was in place prior to this commit). Developers who would like to keep using such tools merely need to highlight their changes and choose the "Format Selection" (or similar) option in their editor. If they choose to use Prettier, no configuration file is necessary; this project is accepting of the default Prettier settings, so long as they aren't used to reformat entire files/code-bases. For more details, please read this incredibly long commit message. I hope it'll help highlight another side to automated, enforced, opinionated code-formatting tools. <3 Code formatting is, as I think this long commit message will continue to point out, a subjective preference. Code formatting tools, like Prettier, have tried to end formatting disagreements by picking a single set of "unwavering" rules. It's hard to win at this, but as long as I'm involved with this project, I will not be nit-picking anyone's choice of code-style so long as it is not intentionally trying to be unnecessarily unorthodox. Also, even if it is, in my opinion, appearing to be unnecessarily unorthodox I pledge to try and understand and be empathetic to the reasoning for it. I would encourage others to evaluate, discuss, and react similarly! At a high-level, my preference is: Try to match surrounding style, leave comments when necessary, try to think about how to best represent your change itself and consider the future of the code — at least briefly. That said, the formatting of code isn't always always best determined by an opinionated tool. On more than one occasion, Prettier has made decisions for this project which have resulted in decreased code clarity in our changesets (i.e. pull-requests; PRs). For example, even removing a single character from a variable can result in a changeset with anywhere from ~2 to several-hundred of lines of unnecessary changes. As a very small example of this, consider [4bd1f90][1], a change to a misspelled variable, which resulted in the Prettification seen in [d6b78d0][2]. Now amplify that change to a large function where the function parameters changed by plus or minute two characters and the hanging indent unnecessarily changes so that it can fit more things on the previous line. When I first ran into the spelling example above, I was bothered and again tempted to remove Prettier. I knew that I had previous examples of this amplified change being problematic, but couldn't quickly dig up an example to make a case. Low and behold, it only took five days before another example came up!: See the relatively simple change in [c413141][3], which stats out to: packages/apollo-server-koa/src/__tests__/ApolloServer.test.ts | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) Now see what Prettier does to this brief change in [8c6fc24][4]: packages/apollo-server-koa/src/__tests__/ApolloServer.test.ts | 1124 +++++++++++++++++++------------------- 1 file changed, 562 insertions(+), 562 deletions(-) With Prettier (or most opinionated automatic code formatting tools), the entire function must now be reformatted when the clarity of the function was not at all in jeopardy! Not only is this unnecessarily changing code, but it also buries "blame" for these changes across an extra ~500 lines of code through repeated rounds of similar re-linting. In my opinion, those additional lines being changed aren't at all useful for the digestibility of a project. When I open a PR, for the success of the code, I prefer that the changes not be clouded with artifacts that make it more difficult for the reviewer to understand. Conversely, when I'm reviewing a PR, I prefer to avoid the same. Unrelated formatting changes — automatic or not — are the most frequent contributors to this pain, in my experience. As lesser, but still related points: It's not at all uncommon for "opinionated" tools to change their opinions. On more than one occasion, I've updated a dependency in this repository only to have to re-format swaths of code: - #846 - #2203 - #2572 Plus, on other occasions, I've had to wade through over-complicated merge conflicts between branches when otherwise capable (Git) merge strategies were sandbagged by formatting differences. All this said, I want to emphasize that I really encourage anyone to use tools that facilitate the automatic formatting of their code. I just ask that they can do it with a limited scope that merely touches the code they're changing (e.g. "Format Selection"). If there is no way to avoid it and it's absolutely necessary to re-format hundreds of lines of code, that's okay! There are certainly cases where very large reformatting is warranted, but it seems better if it's the exception rather than the norm. I hope that there's an understanding that there are times that tools that work for one developer/project/concept, it won't work for another. As a regular contributor to this project, I personally find that Prettier frustrates me more often than it helps me (long-term and short-term considerations both being had). Conversely, I know that Prettier greatly simplifies the workflow for many! I love that! But while someone might really enjoy `editor.formatOnSave` re-formatting their code, imagine my own surprise when it does exactly that. Dialogue and conversation is very welcome here. I certainly don't want to push anyone away from contributing, but I need to also be realistic about my own frustrations. I'm excited for tooling (which apparently doesn't exist yet!) that can help improve this for those on either side of the Prettier picket fence, but until that time comes, I think Prettier will better left to the concern of the developers who wish to employ it. [1]: 4bd1f90 [2]: d6b78d0 [3]: c413141 [4]: 8c6fc24
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
1.15.3
->1.16.1
Release Notes
prettier/prettier
v1.16.1
Compare Source
diff
JavaScript: Do not format functions with arguments as react hooks (#5778 by @SimenB)
The formatting added in Prettier 1.16 would format any function receiving an
arrow function and an array literal to match React Hook's documentation.
Prettier will now format this the same as before that change if the arrow
function receives any arguments.
JavaScript: Add necessary parentheses for decorators (#5785 by @ikatyang)
Parentheses for decorators with nested call expressions are optional for legacy decorators
but they're required for decorators in the current proposal.
TypeScript: Stable parentheses for function type in the return type of arrow function (#5790 by @ikatyang)
There's a regression introduced in 1.16 that
parentheses for function type in the return type of arrow function were kept adding/removing.
Their parentheses are always printed now.
MDX: Correctly recognize inline JSX (#5783 by @ikatyang)
Previously, some inline JSXs are wrongly recognized as block HTML/JSX,
which causes unexpected behaviors. This issue is now fixed.
v1.16.0
Compare Source
diff
🔗 Release Notes
Renovate configuration
📅 Schedule: "after 6pm every weekday,before 5am every weekday" in timezone America/Los_Angeles.
🚦 Automerge: Enabled.
♻️ Rebasing: Whenever PR is stale, or if you modify the PR title to begin with "
rebase!
".🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Renovate Bot. View repository job log here.