Added chained "pipe" function formatting tests

[brodybits]

In response to #6469 (comment) by @lydell, here are a couple of tests that show how Prettier handles the formatting of "pipe" functions and chained "pipe" functions:

• test of input that is clean and correct according to Prettier 1.18.2, unfortunately seems to be made hard to read in the master branch
• another test with some comments that I added, which will keep things on separate lines as I think is what we want.

@lydell please feel free to correct and improve this explanation as you feel would be justified.

I would like to make the following points:

• I do think that the formatting of the input with no comments added is an unfortunate change in this case.
• I have discovered that strategic placement of comments can sometimes help give the user cleaner formatting, in addition to some descriptive insights. I think this is something that should be formally documented and would be happy to work on this (someday).

• I’ve added tests to confirm my change works.
• (If changing the API or CLI) I’ve documented the changes I’ve made (in the docs/ directory)
• (If the change is user-facing) I’ve added my changes to the CHANGELOG.unreleased.md file following the template.
• I’ve read the contributing guidelines.

✨Try the playground for this PR✨

[lydell]

Adding a // comment is a good old trick to force multiline formatting. A // comment requires a newline after it (since it comments to the end of the line) – that’s why Prettier is forced to switch to multiline formatting if a // comment is encountered. (Unless Prettier moves the comment somewhere else, which it does sometimes.)

[brainkim]

Like I said in the original PR, I’m here to help! Ping me if you come up with any ideas/need to understand some code related to call expression splitting. I don’t think the above issue is actionable in its current form but I’m very willing to accommodate requests for new heuristics. I don’t want to be the one to hold up 1.19.

[lydell]

I agree with @brainkim. What’s your intention with this PR, @brodybits?

[brodybits]

Like I said in the original PR

in #6469 (comment) (I am adding the explicit link for the sake of some less experienced Prettier developers such as myself)

What’s your intention with this PR, @brodybits?

I have a feeling that the formatting behavior in this case should be explicitly tested in the test suite, visible if it changes in a minor release. I think the change from 1.18.2 to master that is demonstrated here should ideally be avoided in a minor release.

I also wanted to demonstrate the trick of using comments to get cleaner formatting in some cases, since it was not obvious to me at first. I think it should be documented at some point.

I am fine if you guys want to close this PR.

[lydell]

These are good test cases, so I think we should merge.

[thorn0]

I think these tests should be placed in tests/functional_composition. No need to create a new directory.

[brodybits]

I just moved the new tests into tests/functional_composition and did a clean rebase. The one thing now is that the new test scripts have slightly incconsistent file names, using dash instead of underscore. I personally prefer dash over underscore in file names whenever possible, would be happy to rename if needed.

[fisker]

I did a rebase, should good to merge.