Skip to content
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 2 commits into from
Jan 23, 2019

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Jan 21, 2019

This PR contains the following updates:

Package Type Update Change References
prettier devDependencies minor 1.15.3 -> 1.16.1 homepage, source

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.

    // Input
    ["red", "white", "blue", "black", "hotpink", "rebeccapurple"].reduce(
      (allColors, color) => {
        return allColors.concat(color);
      },
      []
    );
    
    // Output (Prettier 1.16.0)
    ["red", "white", "blue", "black", "hotpink", "rebeccapurple"].reduce((
      allColors,
      color
    ) => {
      return allColors.concat(color);
    }, []);
    
    // Output (Prettier 1.16.1)
    ["red", "white", "blue", "black", "hotpink", "rebeccapurple"].reduce(
      (allColors, color) => {
        return allColors.concat(color);
      },
      []
    );
  • 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.

    // Input
    class X {
      @​(computed().volatile())
      prop
    }
    
    // Output (Prettier 1.16.0)
    class X {
      @​computed().volatile()
      prop
    }
    
    // Output (Prettier 1.16.1)
    class X {
      @​(computed().volatile())
      prop
    }
  • 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.

    // Input
    const foo = (): (() => void) => (): void => null;
    const bar = (): () => void => (): void => null;
    
    // First Output (Prettier 1.16.0)
    const foo = (): () => void => (): void => null;
    const bar = (): (() => void) => (): void => null;
    
    // Second Output (Prettier 1.16.0)
    const foo = (): (() => void) => (): void => null;
    const bar = (): () => void => (): void => null;
    
    // Output (Prettier 1.16.1)
    const foo = (): (() => void) => (): void => null;
    const bar = (): (() => void) => (): void => null;
  • 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.

    <!-- Input -->
    _foo <InlineJSX /> bar_
    
    <!-- Output (Prettier 1.16.0) -->
    _foo
    
    <InlineJSX /> bar_
    
    <!-- Output (Prettier 1.16.1) -->
    _foo <InlineJSX /> bar_

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.


  • If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot. View repository job log here.

@renovate renovate bot added the 🎄 dependencies Updates to dependencies, generally automatically managed by Renovate. label Jan 21, 2019
@renovate renovate bot force-pushed the renovate/prettier-1.x branch from dbba4ba to 8add959 Compare January 22, 2019 10:32
@renovate 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 renovate bot force-pushed the renovate/prettier-1.x branch 5 times, most recently from bedb444 to 9b9caaf Compare January 23, 2019 11:40
@renovate renovate bot force-pushed the renovate/prettier-1.x branch from 9b9caaf to f30fd6b Compare January 23, 2019 12:34
In the constant juggle to appease its ever-changing desires.
@renovate
Copy link
Contributor Author

renovate bot commented Jan 23, 2019

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 rebase to this PR and Renovate will reset/recreate it.

@abernix abernix merged commit 117ea30 into master Jan 23, 2019
@renovate renovate bot deleted the renovate/prettier-1.x branch January 23, 2019 15:56
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
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
🎄 dependencies Updates to dependencies, generally automatically managed by Renovate.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants