Import sorter revamping

[Conaclos]

Biome users have reported several shortcomings with the current import sorter.
This document first reviews the state of the art, including the Biome import sorter and its shortcomings.
It then outlines a proposal that attempts to address these shortcomings.

Note: This is an RFC. It is not the final design.

State of the art

prettier-plugin-sort-imports

This plugin allows its users to sort imports while formatting with Prettier.
If no configuration is provided, the plugin sorts imports using natural ordering of the import sources.

❯ cat index.js
import { ok } from "node:assert"
import { a } from "./mod.js"

❯ npx prettier index.js
import { a } from "./mod.js"
import { ok } from "node:assert"

The plugin allows its users to customize the order by specifying import groups.
In the following examples, 2 groups are created:

{
  "importOrder": ["^node:(.*)$", "^[./]"]
}

All imports that don't match at least one of its groups are third party imports.
The plugin places the third party imports at the start.
This can be changed using the <THIRD_PARTY_MODULES> identifier inside importOrder.
The plugin orders imports inside a group using natural order.

The option importOrderSeparation controls if a blank line is inserted between groups.

The plugin doesn't ensure a total order between imports of different kinds.
For example the two following examples are considered sorted:

import Default from "mod"
import { Named } from "mod"

import { Named } from "mod"
import Default from "mod"

If the option importOrderCaseInsensitive is enabled, the order between imports of a group becomes partial.
This means that the following examples are considered sorted:

import {} from "A"
import {} from "a"
import {} from "b"
import {} from "B"

import {} from "a"
import {} from "A"
import {} from "B"
import {} from "b"

I think it is not desirable.
A user who enables importOrderCaseInsensitive will surely expect a single (total) order between imports.
By enabling importOrderCaseInsensitive, I think a user wants that for any pair of letters, the lowercase, and uppercase variants of the former come before or after the uppercase and lowercase variants of the latter.
By assuming that an uppercase variant comes before its lowercase variants,
a user could thus expect the following result:

import {} from "A"
import {} from "a"
import {} from "B"
import {} from "b"

By default, specifiers in named imports are not sorted.
A user has to enable importOrderSortSpecifiers to sort them.

eslint-plugin-import/order

Similarly to the Prettier Plugin, this ESLint plugin allows customizing import order using groups.
However, it defines a set of predefined groups:

• built-in
  • node built-in module (fs, path, ...)
  • names provided in import/core-modules
• external
  • name that doesn't match import/internal-regex, and
    • name starting with @ (scoped package)
    • name starting with a character (scope-less package)
    • relative path that go beyond the current package root
    • any absolute or relative path that matches
      import/external-module-folders
• parent
  • ../**/*
• sibling
  • ./**/*
• index
  • .
  • ./
  • ./index
  • ./index.js
• internal
  • other relative paths
  • name that matches import/internal-regex
• object
  TypeScript's import assignment import x = y
• type
  • import type
• unknown
  • paths ending with an unknown extension.
    By default, the plugin recognizes only js.
    This can be modified using import/extensions

CJS imports const x = require("") are always ordered after ESM imports.
Thus, ESM and CJS are kind-of super-groups.

Unassigned CJS imports and side effect imports are ignored.

Additionally, the plugin supports custom resolvers to resolve a module.
This allows to support TypeScript's tsconfig paths for example.

The option groups is an array of predefined groups and/or subarray of mixed predefined groups.
Imports of mixed groups may be interleaved according to their alphabetic order.
Omitted predefined groups forms an implicit mixed group at the end.
The current default is ["built-in", "external", "parent", "sibling", "index"].
Example of a custom config:

{
  groups: [
    'built-in',
    ['sibling', 'parent'], // mixed group
    'index',
    'object',
    // implicit mixed group ["external", "internal", "type", "unknown"]
  ],
}

The option pathGroups allows using a glob pattern to categorize the path in a predefined group.
It also allows indicating that the path should be ordered just before or after the predefined group.

{
  "pathGroups": [
    {
      "pattern": "~/**",
      "group": "external",
      // "position": "after",
    }
  ]
}

The option newlines-between controls the insertion of blank lines between groups.
The option takes one of the following value:

• ignore: blank lines are allowed everywhere (default)
• always: require at least one blank line between groups and forbid blank lines inside a group
• always-and-inside-groups: require at least one blank line between groups
• never: no blank line between imports

The option distinctGroup indicates if pathGroups positioned after/before a
predefined group should be considered as distinct groups.
The current default is true.
However, in the future the option should be disabled by default.

The option pathGroupsExcludedImportTypes defines import types that are not
handled by pathGroups.

The option alphabetize allows controlling how to order the imports of the groups.
The order can be ascending, descending, or either (default).
The order can be case-insensitive (by default it is case-sensitive).

ESLint Plugin Simple Import Sort

This plugin sorts each chunks of imports separately.
A chunk is a sequence of lines that contains only imports, comments, and blank lines.
Each chunk is organized into groups (sections in the Plugin terminology) with a blank line between each.
Groups are themselves organized into subgroups.

Also, the plugin sorts re-exports, i.e. export ... from "mod".
Unlike, imports, a comment on its own line starts a new chunk of re-exports.

The default groups (each one with a single subgroup) is as follows:

1. Side effect imports. (These are not sorted internally).
2. Node.js built-in modules prefixed with node:.
3. Packages (NPM packages and Node.js built-in modules without node:).
4. Absolute imports and other imports such as Vue-style @/foo.
5. Relative imports.

The plugin allows you to define your own groups and subgroups.
A regex defines a subgroup.

To determine the subgroup of a given import, the import source is matched against every regular expression.
The import ends up in the subgroup that have the longest regex match.
Imports that don’t match any regex are put together last.

Regexes are extended in a way that allows matching side effect imports and import type.
This allows users to group them.

Import statements in every subgroup are sorted by their import source.
The order is:

• Natural (compares numbers).
• Case-insensitive, but with a total order by falling back to the usual order.
• Alphabetic, using Unicode collation.
• Relative imports/re-exports of files higher up in the directory structure come before closer ones.
  This leads to the following order: ../../utils < ../utils < .
  In short, . and / sort before any other (non-whitespace, non-control) character.
  .. and similar sort like ../, to avoid the "shorter prefix comes first".

If both import type and regular import are used for the same source,
then the type imports come first. Same thing for export type.
import type can be placed in a dedicated group/subgroup by using a custom group.

Named Import and named re-export specifiers are sorted by their external names.
This choice is motivated by stability, because the external name is unlikely to change.
For instance, the following code is sorted:

import { A as B, B as A } from "mod"

export { B as A, A as B } from "mod"

Leading and trailing comments are moved with the statement,
except for leading and trailing comments of a chunk on their own line.
Similarly, leading and training comments on their own line inside a named import are not moved.

// leading chunk comment (don't move)
import {} from ""
// leading comment that moves
import { // leading named comment (don't move)
    /* leading comment that moves */ b,
    // leading comment that moves
    a, // trailing named comment (don't move)
} from ""
// trailing chunk comment (don't move)

This plugin don't handle CJS.

TypeScript import sorting

TypeScript's LSP provides a sort imports action.

TypeScript 5.0 added several options to customize the sorting algorithm.
It also changed its default behavior for automatically detecting if the sorting is case-sensitive or case-insensitive.

By default, it uses an ordinal order that uses a lexicographic binary order.
This can be changed by setting organizeImportsCollation to unicode.
When set to unicode, TypeScript uses the collation order of a given locale.
The locale can be set with organizeImportsLocale and is en-US by default.
Under unicode, natural sorting is used between numbers.
This can be disabled with organizeImportsNumericCollation.

TypeScript places inline-type imports last.
For example, the following code is sorted:

import { B, type A } from "mod";

However, some TypeScript member expressed
the wish of ignoring the type qualifier and more globally to match the behavior of the ESLint plugins.
Ignoring the type qualifier improve stability by avoiding moving the specifier when type is added or removed.

Biome's current design

Imports separated by at least one blank lines form distinct chunks.
Biome groups imports by their "distance" from a user POV.
The groups (in order) are:

1. modules imported via bun: protocol.
2. built-in Node.js modules imported using the node: protocol and common Node built-in modules such as assert;
3. modules imported via npm: protocol.
4. modules that contain the protocol :.
   These are usually considered "virtual modules", modules that are injected by your working environment, e.g. vite;
5. modules imported via URL;
6. modules imported via a bare specifier or a @scoped specifier (libraries);
7. modules imported via absolute imports;
8. modules imported from a name prefixed by #.
   This is applicable when using Node's sub-path imports;
9. modules imported via relative imports;
10. modules that couldn't be identified by the previous criteria;

Imports of a group are ordered using a natural order.

Named specifiers are also ordered in natural order.
If they are aliased (name as alias), we use their aliases to order them.
This is different from the ESLint Plugin Simple Import Sort that uses the imported name, and not the aliases.
A type qualifier of a named specifier doesn't affect the order.
The following example is correctly ordered:

import assert from "node:assert"
import { type B, A as D, type X } from "mod";

Biome users reported several shortcomings with the current design:

• It doesn't allow custom order Specify import groups and automatic add blank lines between them #645, Port `prettier-plugin-sort-imports` to Biome #979
• It doesn't allow adding blank lines between some import kinds Specify import groups and automatic add blank lines between them #645
• Using blank lines to form groups don't play well with auto-import editor's action.
  I didn't find the related comment/issue that points it.
• It doesn't merge import statements Merge imports #454, comment1, comment2
  This could also cover prefer top-level type imports #1660
• It doesn't take into account TS aliases sorting order doesn't take typescript aliases into consideration #1312, Respect tsconfig path aliases when organizing imports #1533
• It doesn't organize export from Sort exports #467

Proposal

All import sorters presented in the state-of-the-art rely on a multi-layered sorting approach to determine the order between import statements.
They organize import statements into groups that are ordered between them, and then use a string-wise comparison of their import source.

This proposal is based on the same approach: first we define import chunks, then we group imports within a chunk before sorting them.
Imports are ranked according to the order of import sources.
Unlike other approaches, we didn't compare the import sources in a string-wise way.
Instead, we parse them into a structured form and compare this form.

Import chunks

An import chunk is either:

1. a sequence of sticky comments (see below), blank lines, and import statements without side effect imports, or
2. a single side effect import - every side effect import consists in a chunk.

In other words, side effect imports, non-sticky comments, and any statement which is not an import acts as a boundary of an import chunk.
Unlike the current Biome import organizer, a blank line doesn't end an import chunk.

A sticky comment is a comment that precedes an import statement.
They must not be separated by any blank lines.

// Non-sticky comment

/* Start Chunk 1 */ import { A } from "1"

// Sticky Comment inside Chunk 1
import { B } from "" /* End Chunk 1 */
/* Start Chunk 2 */ import "" /* End Chunk 2 */
/* Start Chunk 3 */ import "" /* End Chunk 3 */
/* Start Chunk 4 */ import { C } from "" /* End Chunk 4 */
export const CONSTANT = 0;
/* Start Chunk 5 */ import { D } from "" /* End Chunk 5 */

// Non-sticky comment that ends Chunk 5

/* Start Chunk 6 */ import { E } from "" /* End Chunk 6 */

Import source sorting

Import sources are first parsed into a structured form and then compared.

Import sources have many structures:

• Regular paths that start with /, ../, or ./, or is the paths .. or ..

  import {} from "./file,js"

• Bare specifiers that generally are NPM packages or aliases.

  They can be separated between scoped specifiers such as @biomejs/biome and non-scoped specifiers such as jest.

  import {} from "@biomejs/biome"
  import {} from "jest"

• URLs.

  Moreover, some URLs respect a precise format.
  For instance, an esm.sh URL follows this pattern:
  https://esm.sh/<pkg>@<smver>/<path>.

  Here, an example:

  https://esm.sh/canvas-confetti@1.6.0/submodule/file.js
  └─┬─┘  └──┬──┘└──────┬───────┘ └─┬─┘└────────┬───────┘
  scheme authority  package     version       path
  

• Bare specifiers prefixed by a protocol

  import {} from "bun:test"
  import {} from "jsr:@luca/cases@^1.0.1"
  import {} from "node:assert/strict"
  import {} from "npm:@luca/cases@^1.0.1"

• Internal aliases.

  import {} from "#internal/module"
  import {} from "@/internal/module"

  @/ is a convention used by Vue (Webpack aliases)

• And more?

I propose to parse them in a unified way.
We could parse import sources as URI with optional scheme (aka protocol).
The following diagram shows an overview of the unified structure.
It flows from left to right and top to bottom.
#intera\nal and @/ could be handled as a path.

 ┌─────────┐ ┌───────────┐ ┌────┐
─┤protocol:├─┤//authority├─┤path│
 └────────┬┘ └──────────┬┘ └───┬┘┌───┐ ┌────┐
──────────┴─────────────┴──────┼─┤pkg├─┤@ver│
                               │ └──┬┘ └───┬┘┌────┐ ┌──────┐
                               └────┴──────┴─┤path├─┤?query│
                                             └───┬┘ └─────┬┘┌─────┐
                                                 └────────┼─┤#frag├─
                                                          │ └─────┘
                                                          └─────────

The comparison of import sources relies on the structure of the import sources.
A Missing component is placed after a present component.
For instance, an import source without protocol is placed after an import source with a protocol.
A bare specifier (pkg) is placed before a regular path.

Paths are also parsed and ordered in a structural way:

1. aliases that start with @/ or #
2. absolute paths that start with /
3. relative paths that start with .. or .

Path components could be ordered such as .. is placed before . that is itself placed before text.
This allows to use an order analog to ESLint Simple Sort which orders paths in terms of location proximity.

Component are compared in a string-wise way.
It seems that the community is slowly going towards Unicode collation with numerical ordering.
Most of the time, import source are expected to be in ASCII and Rust has not yet mature libraries for internationalization, including collation.
Thus, I propose using case-insensitive natural sorting with code point order as tiebreaker.
Examples of an ordered list of strings:

A
a
a9
a10
B
b

Note that this diverges from the current Biome import sorter.
In the current Biome import sorter, all uppercase characters come before all lowercase characters.
This solves #2162 and is more in line with the direction taken by other import sorters.
Specifiers of a named import statement are also sorted using this order.

Let's take an example of ordered import sources:

bun:test
https://esm.sh/@biomejs/biome
https://esm.sh/@biomejs/biome@1.7.0
https://esm.sh/biome/subpath
https://esm.sh/@biomejs/biome@1.7.0/subpath
jsr:@biomejs/biome
jsr:@biomejs/biome@1.7.0
jsr:@biomejs/biome/subpath
jsr:@biomejs/biome@1.7.0/subpath
node:assert
node:assert/strict
@biomejs/biome
@rome/tools
ava
#internal
#internal/subpath
/absolute
/absolute
/absolute/subpath
../../greatparent
../../greatparent/subpath
../parent
../parent/subpath
./././relative
./relative
./relative/file.js

Although the way of comparing import sources is different from the current Biome import sorter, this should marginally change the order that users currently observe.
I think the resulting order is good enough.
If users are not satisfied, they can use import groups, as described in the following section.

Import groups

Import statements within an import chunk are grouped before being sorted within each group.
A group can de defined by a glob pattern.
Groups are defined inside a list.
Groups are ordered in a chunk in the order that they appear in the list.
An import belongs to the first group that it matches in the list.

For example the following list: ["node:**", "#**", "**"] results in this organization:

+ import assert from "node:assert"
  import assert from "#internal"
  import assert from "other"
- import assert from "node:assert"

The last group ** can be omitted, because Biome has an implicit group that collects all remaining imports.
Thus, an import always matches at least the (last) implicit group.

Some special identifier are mapped to predefined groups:

• <bun>: all imports that start with bun: and also bun
• <node>: all imports that start with node: and also node built-in modules that are not a dependency in package.json
• <scoped-bare-specifier>: e.g. @biomejs/biome
• <bare-specifier>: e.g. ava, and also scoped
• <relative>: all imports that start with ../ or ./, or are exactly .. or .
• <blank-line>: allows separating two groups with a blank line.
• <types>: all import type
• Others?

For example, the following code is sorted according to ["<node>", "<blank-line>", "<bare-specifier>", "<blank-line>", "<relative>"].

import assert1 from "node:assert";
import assert2 from "assert";

import test from "ava"

import { A } from "./a.js"

Note that requesting for two consecutive blank lines is not forbidden, however the Biome formatter will merge them into a single blank line.
Also, a group (except blank line) should not appear twice in the list because the second apparition will never be matched.

Note: I proposed the syntax <predefined-group>.
However, I am open to suggestion. I also thought about :predefined-group:. Any opinion?

Also, instead of using plain globs, we could use a structured matcher.
For example { protocol: "node" } could match anything with the node protocol.
Globs could still be used to match several protocols or a specific path: { protocol: "{node,bun}", package: "assert{,/strict}" }.

Order between import kinds with identical source

Distinct import kind with an identical source are always ordered in the following order:

1. Default Import Type import type defaultType from "x"
2. Default Import import defaultName from "x"
3. Default NameSpace Import import defaultName, * as ns from "x"
4. Default Named Import import defaultName, { Name } from "x"
5. NameSpace Import Type import type * as ns from "x"
6. NameSpace Import import * as ns from "x"
7. Named Import Type import type { Name } from "x"
8. Named Import import { Name } from "x"

The logic of this ordering is:

• Place Default Import first because it appears first on grouped imports.
• Place grouped imports in second: Default NameSpace Import followed by Default Named Import.
  This order is induced by the order between NameSpace Imports and Named Imports.
• Place NameSpace Import in third position because it allows importing several symbols,
  making it more "gross" than named imports
• Place named imports last.

Note that if the predefined <types> group is in the group list, then all import type are grouped together.

Order between imports with identical kind and source

Imports can have the same kind and source.
This is for example the case of two default imports:

import B from "mod"
import C from "mod"

or when import attributes are present:

import A from "mod" with { type: "json" }
import B from "mod"
import D from "mod" with { type: "macro" }

In this case, imports are sorted using the first imported name.

Import and export merging with identical source

The import organizer merges the import statements when it is possible.
Because this conflicts with our stability goal, we should certainly provide an option to disable/enable import statement merging.

First, the import organizer merges imports with same kind, source, and attributes.
For example:

- import { C } from "2"
- import { D } from "2"
+ import { C, D } from "2"
  import { G } from "2" with { type: "json" }
- import { E } from "2" with { type: "macro" }
- import { F } from "2" with { type: "macro" }
+ import { E, F } from "2" with { type: "macro" }

Note that Default Imports (and NameSpace Imports) from a same source cannot be merged.
This kind of duplication should be reported by a linter rule.
Moreover, we should not merge two side effect imports with a same source.

Second, it merges imports of different kinds into grouped imports.
Default NameSpace Imports are preferred over Default Named Imports (this follows their kind order).
Some examples:

- import A from "1"
- import { B } from "1"
- import * as C from "1"
+ import A, * as C from "1"
+ import { B } from "1"

- import D from "2"
- import { E } from "2"
+ import D, { E } from "2"

- import F, { G } from "3"
- import * as H from "3"
+ import F, * as H from "3"
+ import { G } from "3"

Also, if import type doesn't belong to a dedicated group, then import type {} is merged with import {}, but if the predefined <types> group is used in the group list.

- import type { A } from "1"
- import { B } from "1"
+ import { type A, B } from "1"

If the predefined <types> group is in the group list, then all inline types are extracted to a dedicated import type.

- import type { A } from "1"
+ import type { A, C } from "1"
- import { B, type C } from "1"
+ import { B } from "1"

Grouped import type and export type

When all specifiers of a named import or of a named export have a type qualifier, then type is factorized into a grouped import type or export type.

- import { type A, type B } from "1"
+ import type { A, B } from "1"

- export { type A, type B } from "1"
+ export type { A, B } from "1"

Organize export from

We should also order export from because they are kind of imports that directly re-export.
Export chunks could follow the same logic as import chunks.
Exports could be directly sorted inside a chunk without grouping capabilities.

[arendjr]

Excellent writeup, and very onboard with the proposal!

The only thing I’m not sure about is the <types> group. It feels like it may be undesirable if that group contains all the types regardless of which group the non-type imports from the same module would belong to. It makes me wonder if we would need combined groups such as <node>:<types>, or something similar. Then again, I think I would personally be happiest to not specify the <types> at all and have them grouped with the regular imports, so just thinking out loud here.

<relative>: all imports that start with ../ or ./

Nit: . and .. are valid relative imports as well.

[kaumac]

Grouping by types is not something I've never done before, but thinking about it does make me want to try it, sounds like a good idea to make clear a block/group contains only types.

If I understand correctly this behavior would be opt-in, right? If you want it you explicitly add "<types>" and otherwise it doesn't happen.

[Conaclos]

It makes me wonder if we would need combined groups such as :, or something similar.

Oh yeah, I forgot about that. I think it might be better to remove this predefined group or otherwise use a subgrouping strategy like I described in this comment.

[kaumac]

I've been waiting so long for this and the waiting paid off! Thanks for the great work on the RFC @Conaclos !

My only reservation is that I think explicit scoped specifiers (@something/ for example) should take precedence over <scoped-bare-specifier>.

For example, I have a company monorepo with several internal packages. So if I specify a pattern to match @myCompany/, I'd like them to be grouped separate from other scoped packages. For example:

import {x} from '@biomejs/biome'
import {y} from '@tanstack/react-query'

import {x} from '@myCompany/pkgA'
import {y} from '@myCompany/pkgB'

Not sure if that made sense? 😅

[ayuhito]

I agree. This pattern is very common with Typescript path aliases:

{
  "compilerOptions": {
    "baseUrl": ".", // root of your "paths" below. Required if "paths" is defined
    "paths": {
      "@components/*": ["src/components/*"] // enables us to use @components/MyComponent
    }
  }
}

[Conaclos]

The custom configuration should cover your case with a caveat: the order will be reversed.
If you write the list ["@myCompany/**", "<blank-line>", "<scoped-bare-specifier>"], then you will get the following output:

import {x} from '@myCompany/pkgA'
import {y} from '@myCompany/pkgB'

import {x} from '@biomejs/biome'
import {y} from '@tanstack/react-query'

Note: using the list ["<scoped-bare-specifier>", "<blank-line>", "@myCompany/**"], will have no effect because all scoped packages are matched by the first group.

We could avoid the caveat by continuing to sub-group imports. Imports with a subgroup could be placed after imports without subgroup.
For example, assuming the list ["<scoped-bare-specifier>", "<blank-line>", "@myCompany/**"] @myCompany/pkgA, @myCompany/pkgB, @biomejs/biome and @tanstack/react-query match <scoped-bare-specifier>. They belong to the same group. Only @myCompany/pkgA and @myCompany/pkgB match @myCompany/**. They belong to the same subgroup. We get the following sorting:

import {x} from '@biomejs/biome'
import {y} from '@tanstack/react-query'

import {x} from '@myCompany/pkgA'
import {y} from '@myCompany/pkgB'

[kaumac]

Unless there are downsides to subgroups, that sounds more appealing to me @Conaclos .

Out of curiosity, what happens if an import matches more than one subgroup? I do think this is very much an edge case, it's mostly out of curiosity.

But I like the subgroup approach.

I feel like it's a somewhat common pattern to organize imports from top to bottom from global to specific, for example

• react imports
• third party imports
• project specific imports (like ‘@components/‘)
• project local imports (like ./file.js)

So being able to keep custom scoped imports at the bottom will help to maintain that pattern.

[Conaclos]

Out of curiosity, what happens if an import matches more than one subgroup? I do think this is very much an edge case, it's mostly out of curiosity.

A subgroup can itself includes subgroups. Each match creates a (sub)group in the group created in the previous match, but the first match that creates the root group.

[EfstathiadisD]

Excellent. I use the trivago prettier plugin which is real close to the prettier example. One thing that might be beneficial is to have a setting to include blank lines between groups so groups can remain pure string based groups. Aside from that excellent! Waiting for it with great anticipation! 💯🎉🥰

[Conaclos]

I opened the issue #3177 to fund the implementation of this RFC.

[SinaKarimi7]

Very detailed proposal! I'm looking forward to seeing this added soon and being able to use it in various projects.
Until now, the only reason I haven't migrated projects to the biome is the import sorter.

For example, we have this in our tsconfig file:

/* Path resolving */
"paths": {
    "@/*": ["./src/*"],
    "/*": ["./public/*"]
}

And I use this method to keep the import sorted as the project needs in .eslintrc.json:

So as a user of the biome, I'm thrilled about having the feature to specify custom ordering for different groups of imports✌🏼

[matsko]

Any movement on this? I'm sure a lot of people are waiting on this final piece before they can put your beautiful tool to good use :)

[Conaclos]

We are waiting for funding. See the related issue: #3177

[matsko]

For anyone whom wants something in the meantime before this feature is built, just use prettier with defaults similar to biome.json and run the sorted imports check first. Then run biome immediately after, but have it ignore import sorting. When you do a format check in the CI, just have it only run biome check (the imports will be ignored). This solution isn't perfect, but it's still quite fast. You can also then just turn off prettier once Biome gets its funding and gets the feature built.

[KurtGokhan]

This may be more related to the unused imports rule, but will there be an option to remove empty imports? By empty I mean imports like this:

import {} from 'A';

For stability, it makes sense to not remove this import. But usually this kind of code is unintended. It is an artifact of the unused imports rule fix. If user wants the side effects from module A, they should write one of these:

import 'A';
import * as A from 'A';

Any thoughts about this?

[Conaclos]

noUnusedImports already removes the import statement if it removed the import that was unused.

I am not sure if it is the responsibility of the import sorter or noUnusedImports to remove an empty import statement.

[KurtGokhan]

Ok, I thought it didn't remove empty imports but I guess it is a bug in noUnusedImports. It doesn't remove when there are multiple imports. For example:

import { X, Y } from 'A';

After fix this becomes

import {} from 'A';

This only happens in IDE (VSCode) though. I don't know why it works correctly in CLI but not in IDE.

And there is no option to remove imports like this in noUnusedImports as far as I am aware.

By the way, I think it is logical to say this is a responsibility of noUnusedImports rather than import sorter/organizer. Should I open an issue about the bug and the new option to remove empty imports?

[Conaclos]

This only happens in IDE (VSCode) though. I don't know why it works correctly in CLI but not in IDE.

Interesting.
@ematipico @Sec-ant
Have you some clue why this works on the CLI and not in IDE?
Perhaps the CLI applies a fix and then invalid other fixes in the file. The linter is run again, and we end up with the fix that removes the unused import and the statement.
While in the IDE, all fixes are performed?

Anyway I think we could improve the rule by analyzing an entire import statement at once.
This allows us to properly remove import statement that include only unused imports.
Also, this could reduce the occurrence of some bugs such as #3383.

Should I open an issue about the bug and the new option to remove empty imports?

I don't think we need an option for that. The rule could do that by default.
You can open an issue (task) about that :)

[ematipico]

I suspect the issue isn't us, but the LSP client.

In the LSP, we don't directly apply code actions, but it's the client in charge of that.

Perhaps, the order of the code actions passed to the LSP is causing the issue, however we need to understand if it is a generic client issue or a VSCode one.