What happens if you have three nested functions and one block of code inside and the range of the block of code. Will it reformat the arguments of the nested functions?

Well, it reformats the arguments to the extent that concrete syntax tree (CST) information outside the arguments themselves is discarded, so whitespace around the arguments is removed. However, the arguments themselves stay formatted as they were originally. For example, given nested.js consisting of this code:

function ugly ( {a=1,     b     =   2     }      ) {
  function ugly ( {a=1,     b     =   2     }      ) {
    function ugly ( {a=1,     b     =   2     }      ) {
             `multiline template string
              with too much indentation`
    } // The [163, 251) range selects from the innermost function body's opening brace to this closing brace (inclusive). You can verify this with `dd if=nested.js ibs=1 skip=163 count=88`
  }
}

Running prettier nested.js --range-start 163 --range-end 251 yields the following:

function ugly({a=1,     b     =   2     }) {
  function ugly({a=1,     b     =   2     }) {
    function ugly({a=1,     b     =   2     }) {
      `multiline template string
              with too much indentation`;
    } // The [163, 251) range selects from the innermost function body's opening brace to this closing brace (inclusive). You can verify this with `dd if=nested.js ibs=1 skip=163 count=88`
  }
}

whereas simply running prettier nested.js yields:

function ugly({ a = 1, b = 2 }) {
  function ugly({ a = 1, b = 2 }) {
    function ugly({ a = 1, b = 2 }) {
      `multiline template string
              with too much indentation`;
    } // The [163, 251) range selects from the innermost function body's opening brace to this closing brace (inclusive). You can verify this with `dd if=nested.js ibs=1 skip=163 count=88`
  }
}

I'm not sure if there's a good way to make the arguments completely untouched (and handle other cases like the if one above), other than by going into genericPrintNoParens (and its helpers) and checking the loc of every node before deciding how to print it.

Given that, I could add a disclaimer in the documentation saying that nodes surrounding the given range may suffer some slight reformatting.

It may also change the indentation of the entire code :(

What I had in mind was closer to your original implementation: we look upward to the first statement, check its indentation and re-indent it based on it. If you select more than one statement, then indent all of them.

I think that's a bit more complicated on prettier side but would lead the best results.

What do you think?

It may also change the indentation of the entire code :(

Yeah, it does, unfortunately. That's probably a show-stopper for many use cases.

What I had in mind was closer to your original implementation: we look upward to the first statement, check its indentation and re-indent it based on it. If you select more than one statement, then indent all of them.

Ah, I think I'm starting to see it now. Maybe a good middle ground would be:

• Require that the range exactly covers an integer number of lines of the input
• Detect the indentation of the line the range starts on
• Format the range's substring using printAstToDoc
• Add enough indents to the doc to restore the detected indentation
• Format the doc to a string with printDocToString
• Prepend/append the original input before/after the range

This could be extended later, of course, but it seems like a nice MVP.

Yeah, that's it! Do you want to try it out?

Sure, I just pushed up 44bfd9b trying it out (see the commit message for more details). However, it looks like wrapping a bunch of indents around the doc isn't enough to get printDocToString to actually indent it. Any ideas? I'm not yet familiar enough with how the doc-builders are intended to be assembled.

Actually, I spoke too soon. After a bit more debugging, I found that hardlines seem to trigger the indentation, so I added one in printAstToDoc(), then removed the resulting newline in format() (see c1a61eb). I feel like there's probably a better way of doing this, though...

I'm currently in vacation with spotty internet and only my phone so won't be able to do an indepth review until next week, but some comments.

No problem, feel free to ignore this for the rest of your vacation :)

I think that if you are only doing text based ranges, you should automatically use the beginning of the rangeStart line and same for the end, otherwise it's going to be super annoying to have to select exactly those and throw if not.

Good call. I had considered that, but didn't implement it quite yet. It shouldn't be too difficult, though.

I also do think that the ast based one where you group by statements shouldn't be too hard to implement and feel much better as you can select any sub range and it'll do the right thing.

Yeah, that would be ideal. I don't yet understand how that would work with the indentation detection, though, assuming it allows you to format partial lines. Maybe it'll make more sense as I keep working on the line-based version.

Thanks so much for driving this, it's going to be awesome, it's a much requested feature!

Glad to help, I'm looking forward to having it available!

This is a great feature!
My only concern is what should happen when the selected range contains code with an invalid syntax? Most editor integration will show a red message about that.

Would be interesting to discus about the possibility of parsing invalid grammar or syntax. I know there was the discussion for Babylon.

Code looks really good, thanks! If you move the two little utilities in their respective files, I'll merge this :)

Thanks for the merge! My work on cursor translation (#1637) has given me some ideas on how to extend this to support formatting any range, without changing the code outside of it, so hopefully I'll have that ready at some point as well.

Yay!