chore(deps): update dependency prettier to v1.11.1 #846
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]](https://avatars.githubusercontent.com/in/2740?s=60&v=4){kind=small}
renovate
bot
added
🎄 dependencies
renovate
bot
force-pushed
the
renovate/prettier-1.x
branch
5 times, most recently
from
13eacc8 to
365bb49
Compare
renovate
bot
changed the title
renovate
bot
force-pushed
the
renovate/prettier-1.x
branch
5 times, most recently
from
4cfb766 to
0778d69
Compare
renovate
bot
force-pushed
the
renovate/prettier-1.x
branch
7 times, most recently
from
95dfa14 to
dd96b55
Compare
renovate
bot
force-pushed
the
renovate/prettier-1.x
branch
from
dd96b55 to
7b356ce
Compare
|
Merging as is. Tests are "failing" because of Happy if someone would enlighten me to why any of this is happening, but pretty-ier frustrating right now! |
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 Pull Request updates dependency prettier from
v1.10.2tov1.11.1Note: This PR was created on a configured schedule ("after 10pm every weekday,before 5am every weekday" in timezone
America/Los_Angeles) and will not receive updates outside those times.Release Notes
v1.11.0v1.11.1link
Commits
v1.11.0
0109333Mention webstorm built-in support on homepage (#4037)a066812Do not require plugins to set 'since' field (#4038)5153b15Respect EditorConfig when--configis passed (#3992)29ef3f0Enhancing pre-commit bash script documentation. (#3638)c1107a8feat(markdown): respect tabWidth for list items (#3990)9ee113cwebpack/webpack now uses Prettier (#4039)7919603Webpack -> webpackca81beffix(markdown): list prefix: no unnecessary trailing spaces (#4042)b6c2789fix(markdown): list prefix alignment: count spaces from correct place (#4041)65b988afeat: ignore non standard IE filter values (#4028)efd5bdeFix(typescript) non-null identifier same line in chain (#4052)4ddf1a6fix: don't lowercase nesting selector (#4048)b1b504f1.11 Release Notes and Changelog (#4035)v1.11.1
82492deBump version to 1.11.051202f4Format 2-26 blog post with prettier74a132cBump own prettier dependency version to 1.11.0 (#4058)23f032fFix @orta's link (#4060)d05a29dAllow plugins to override default options (#3991)0ce4ce3fix(api): no regression for deprecated parser (#4072)2897c95Try to clarify when to use the issue template (#4059)This PR has been generated by Renovate Bot.