Always separate out `<TYPES>` into separate line, but keep adjacent to identical value imports

[vincerubinetti]

Preamble:

First off, thanks for this plugin. It's saved me so much sanity, and I've found you to be very open-minded maintainers (which sadly many are not), especially for a plugin striving to be opinionated. I remember you being flexible with the CSS at bottom/top discussion despite its possible footguns with sideeffects, and I've gotten lots of use out of the feature.

Finally following up on this and creating an issue to gauge how many other users also want this.

I do want this, but even I am not sure it can/should be implemented.

I got tired of AI-auto-imports mixing and matching type-import styles, found that @typescript-eslint/consistent-type-imports considers it a wont-fix and just recommends import/consistent-type-specifier-style, looked towards this package, and discovered I had already tread this exact path a few years ago 😅 I could install the eslint import package, but it's heavy for just one rule, plus the config of this package is way more flexible and easy.

---

Related:

#147 (comment)
#185 (comment)
#107

The goal would be to turn something like this:

import { valueA, type TypeA, type TypeB } from "package-a";
import { valueB, type TypeC, type TypeD } from "package-b";

into this:

import { valueA } from "package-a";
import type { TypeA, TypeB } from "package-a";
import { valueB } from "package-b";
import type { TypeC, TypeD } from "package-b";

without having to manually specify something like this (which is what makes this tricky):

[
  "package-a",
  "<TYPES>package-a",
  "package-b"
  "<TYPES>package-b",
]

---

In more detail, here's my importOrder, which tries to order things into my own categories of high-level to low-level, loosely: framework/platform-level 3rd party → other 3rd-party → my functions → local imports

[
  "^react",
  "^@[a-zA-Z]",
  "^[a-zA-Z]",
  "^@/",
  "^/",
  "^./",
  "^../"
]

If I duplicate each of these with a <TYPES> version, that does what it's designed to do, but it doesn't for example keep the type imports within one of those categories adjacent to each other.

That is, you get:

import Analysis from "@/api";
import Badge from "@/components/Badge";
import type { AnalysisType } from "@/api";
import type { BadgeType } from "@/components/Badge";

instead of:

import Analysis from "@/api";
import type { AnalysisType } from "@/api";
import Badge from "@/components/Badge";
import type { BadgeType } from "@/components/Badge";

---

To be honest, I can't think of how this could be elegantly integrated into the current API. But maybe someone else can.

For now, I've taken to just doing this:

[
  "<TYPES>^react",
  "<TYPES>^@[a-zA-Z]",
  "<TYPES>^[a-zA-Z]",
  "<TYPES>^@/",
  "<TYPES>^/",
  "<TYPES>^./",
  "<TYPES>^../",
  "^react",
  "^@[a-zA-Z]",
  "^[a-zA-Z]",
  "^@/",
  "^/",
  "^./",
  "^../"
]

Not ideal, but I view it as better than mixing and matching type and value imports on the same line, or worse yet inconsistently doing mixed/separated styles.

[IanVS]

Hi @vincerubinetti, glad you're getting good use out of the importOrderSafeSideEffects option.

Thanks for bringing up this use case as well. I don't have any good suggestions off the bat. The <types> keyword is fairly flexible, but unfortunately not enough for what you need. I will also be curious to hear if others would like this kind of style, and maybe we can come up with something to accomplish it. Though, I'm pretty reluctant to add additional configuration options, as you know. ;)

[fbartho]

@vincerubinetti silly question: why is this a goal? I can't think of a non-stylistic benefit to doing that. I'd love to learn the purpose of this format. If you're using AI intentionally, then this plugin should be all you need from a functional level. Extracting the types to be adjacent using the import type line seems idiosyncratic vs just forcing them to always be regular imports.

Type-aware-Compilers or runtimes will already strip the type imports? Are you making your own build-tool, and want to easily strip the type-imports? If you're allowing regular imports from a module, enforcing the split into types/non-type imports doesn't produce a different outcome, does it?

If the answer is you just like that style, then I retract my question! Everyone has their own preferences.

[vincerubinetti]

Oh i'm not a library maintainer or anything, this is just for my own DX.

This is personal preference, and so I can quickly find what I'm looking for. The category-level split helps me find e.g. a react function or a local json import. Then once I scan to the right section, I find the specific library I want, then ideally I could find the types for that library right below it.

But I can also get used to having the whole import section be split by all types first then non types.

And as for splitting the types from the values ... several reasons. Probably most important is I actually find it results in less lines, because when they're combined, the type keyword gets repeated a lot, which leads to exceeding the prettier print width, which leads to it getting spread across 10 lines when it could've fit in 2. I also find it easier to add/remove when they're split, and determine which functions and such I'm importing at a glance.

[ammut]

We've encountered this issue as well, so here are our thoughts about this: In our use-case, we're using 'eslint-plugin-import''s rule 'import/consistent-type-specifier-style' with the 'prefer-top-level' option, i.e. prefer this:

import type { A } from 'a';
import { a } from 'a';

over this:

import { type A, a } from 'a';

Typescript will strip the type imports either way, leading to the exact same result, but we prefer one duplicated import statement over potentially multiple duplicated type markers. This also has the benefit of occasionally fitting the imports on two lines when the inline style would have to break and put each specifier on a separate line, which reads a bit noisy. In other words, just what vincerubinetti explained above.

Given all that, the main desired outcome is simply to reduce git commit noise. When both type-first:

import type { ... } from 'a';
import { ... } from 'a';

and type last:

import { ... } from 'a';
import type { ... } from 'a';

are accepted, we occasionally get MRs where some files have tons of changed lines, but its just that the order of some of those imports was swapped. And Prettier is all about deterministic behavior, in our eyes.

So: We're also strongly in favor of this issue, however, we don't think this needs a configuration option. Just deterministically putting one before the other would be a huge improvement. Although our preference would be type imports first.