import multiline optimization #13353
Conversation
|
I(Personally) like things vertically one by one, I even use empty comment to prevent Prettier collapse to one line in some case. Same opinion here |
|
Easier to reorder Alt + ↑, delete Ctrl + X |
|
Looks like a reasonable tradeoff to me. |
| import { numberValue1 as numberValue8, numberValue2 as numberValue9 } | ||
| from "./ES6_ExportAllFromMulti"; | ||
|
|
There was a problem hiding this comment.
Hmm not sure I prefer this over the original 🤔
Even where there is no as, new formatting makes a bit harder to scan through names. AFAIU, the main benefit we should expect from the change is the reduction of lines of code. But what does it improve in DX? Existing approach optimizes for cognitive ease and clean git diff – that will be a shame to lose.
There was a problem hiding this comment.
Good point about as. The current formatting seems to work better for such imports.
As for clean diffs, I think the proposed formatting might be an improvement in that regard. Currently, the diff isn't clean when switching between the single-line and multi-line formatting happens. With the proposed formatting, that switching is seemingly going to happen less often, and the diff for switching single-line⇄double-line is quite clean, definitely cleaner than single⇄multi.
There was a problem hiding this comment.
Just realized I'm used to diff viewers that highlight in-line diffs like this:
And you're probably talking about raw unhighlighted output of git diff. That makes me wonder how many people view diffs without in-line highlighting and why they would do that.
There was a problem hiding this comment.
But what does it improve in DX?
Less scrolling through something that is edited mostly by tooling (auto-import, linters for sorting imports and removing unused ones), not manually? I wish we had some statistics on how many developers edit imports manually. That'd put this proposal in a good perspective. I guess these people are already in minority, but that's only a guess.
There was a problem hiding this comment.
I never need write code more than 200 lines. Split the file, if it's too long, that's what ES Module for.
There was a problem hiding this comment.
auto-import
I have these lines in my vscode settings
"javascript.suggest.autoImports": false,
"vetur.completion.autoImport": false,
"volar.completion.autoImportComponent": false,There was a problem hiding this comment.
I have these lines in my vscode settings
I'm surprised. To me, this is like formatting code manually instead of using Prettier. The only problem I ever had with auto-import has been fixed in TS 4.8. Do you think there are many people who share you preferences in this regard?
There was a problem hiding this comment.
also didn't know that someone these days moves imports manually)
Hi @GlebDolzhikov, what parts of that issue aren't getting fixed? Also, will this be an opt-in feature? I think that's the best middle ground for an otherwise ... hotly debated proposal. Will this be implemented? There was quite the pushback when someone stated it likely wouldn't be added. @thorn0 @fisker @kachkaev @thdomingues-dev |
Description
partly fixes #5995
Checklist
docs/directory).changelog_unreleased/*/XXXX.mdfile followingchangelog_unreleased/TEMPLATE.md.✨Try the playground for this PR✨