Split imports onto multiple lines based on print width

[NashJames]

Is your feature request related to a problem? It's quite easy to end up with files much longer than necessary due to many imports from a single path. E.g:

import { 
   IconA,
   IconB,
   IconC,
   IconD,
   IconE,
   IconF,
} from 'icon-library';

Describe the solution you'd like Have imports split into multiple new lines. E.g:

import { IconA, IconB, IconC, IconD } from 'icon-library';
import { IconE, IconF } from 'icon-library';

Potentially should be an optional config option as to not be a breaking change.

Describe alternatives you've considered Not sure there is one.

Additional context Add any other context or screenshots about the feature request here.

[fbartho]

It should already respect print-width! (And does in my project). Would you mind sharing a full sample, with your prettier config file?

[NashJames]

Sorry accidentally somehow tabbed to the submit button early. Any clearer now?

[fbartho]

Yeah! much clearer @NashJames.

At the very least this feature would need one or more configuration flags. And that complexity would potentially run the risk of needing to round-trip out to prettier, or to invert prettier's algorithm for wrapping to line width.

I happen to know that's pretty complex code within prettier / to do correctly -- which therefore comes with a bunch of code complexity and maintainability costs. -- In some ways this is inverting the purpose of this plugin!

---

My snap opinion: I don't think I could endorse building this feature into the plugin.

Formatting code this way would be incredibly frustrating for humans to do by hand so would only ever be done because a tool is doing it for you. And refactoring to rename any of the symbols would trivially cause lots of reflows / git thrash. The aesthetic niceness of not seeing line wraps doesn't seem to justify the cost for me.

I think if @IanVS really feels it's valuable we could go forwards, but I'm not in support of it.

[NashJames]

Totally understand the point about maintainability. The rest is all very understandable, especially as I've very little idea myself what the complexity of this would be.

I've spent a good few months working on a large Rust project where imports are much much cleaner; and now returning full-time to Typescript, imports stand out very obviously as a bit of information overload.

Could there be an alternate solution to the issue?

Perfectly happy for this to be closed if we don't turn up any viably good options.

[fbartho]

I wouldn’t object to keeping this ticket open for a while to see if we can brainstorm solutions here! I do feel your pain from being a multi-language coder.

I wonder in this case if you are being bothered by something that might be fundamentally a choice in the JS&Friends ecosystem that disagrees with a comparable choice made by Rustaceans?

[NashJames]

I wonder in this case if you are being bothered by something that might be fundamentally a choice in the JS&Friends ecosystem that disagrees with a comparable choice made by Rustaceans?

I'd say almost definitely. Here's a complex Rust example incase you haven't seen one:

use crate::{
    folder1::subfolder1::{
        NAMED_IMPORT1, NAMED_IMPORT2, NAMED_IMPORT3, NAMED_IMPORT4, NAMED_IMPORT5, NAMED_IMPORT6,
    },
    folder2::named_import7,
    folder3,
    folder4::{self, named_import8, named_import9},
};
use library1::NamedImport10;
use library2::NamedImport11;
use library3::{librarySubfolder1::NamedImport12, librarySubfolder2::NamedImport13};

Something similar could take JavaScript/TypeScript 40 lines. But this is a fairly core decision within the Rust language and so not really transferable to JS/TS at the moment. Obviously these kinds of decisions are up to the folks behind ECMAScript (admittedly they've already made massive improvements with ESM).

It may be there's no good solution without major specification changes, but I figured I'd open this ticket and see anyway.

[IanVS]

Thanks for the ticket, @NashJames. I agree with @fbartho that this isn't something we should do in this plugin. It's related to imports, but this plugin is really just intended to sort imports, we leave the formatting decisions to prettier itself. So if anything, this seems like it could be a request to prettier to change the way it prints import specifiers, though honestly I don't foresee them changing it. That said, I agree that it could be improved, though actually implementing it could be tricky.

I wonder if you might want to consider creating your own plugin to accomplish this. If you're not changing the AST (as we do), it should be compatible with this plugin. Might be worth an experiment anyway.