organizeImports relative imports at the end

[Conaclos]

Description

For now, Rome sorts imports regardless if there are relative or absolute / bare specifiers.

In order to have a behavior closer to existent import sorters, such as the one exposed by TypeScript LSP, I propose to place relative imports at the end of an import section.

Currently, the following import section is organized according to Rome:

import { x } from "./x.js"
import assert from "node:assert"

With this proposal, the imports will be re-organized:

import assert from "node:assert"
import { x } from "./x.js"

[lcswillems]

That looks good!

In my case I would like imports in this order:

• node imports
• package imports
• absolute internal imports
• relative internal imports

[lcswillems]

In my case, I currently use the prettier-plugin-sort-imports plugin of ianvs.

And this configuration in my package.json:

"prettier": {
  "importOrder": [
    "^~(.*)$",
    "^\\$(.*)$",
    "^[./]"
  ],
  "importOrderBuiltinModulesToTop": true,
  "importOrderMergeDuplicateImports": true,
  "importOrderCombineTypeAndValueImports": true
},

The most important setting is "importOrder". The other ones are less important.

[ematipico]

There's also the fact that configuration creates friction because the developer ends up playing with configuration instead focusing on business logic.

If Rome needs to expose such a configuration, we must justify it well. Here we have no precedent. The prettier plugin does its own thing, and the eslint plugin does its own.

Few things about import sorting:

• in JavaScript, import sorting has limitations because the language has side effects;
• given the first bullet point, import sorting is not about formatting anymore;
• import sorting is about analyzing the entire project and make sure that soring imports is safe;
• if there's an importOrder, for example, and Rome won't place a specific import in the right place because of a side effect (this assumes that Rome will know that a module has a side effect), what would the user do?

That's why I am a bit hesitant about adding configuration. I want first to create expectations and then ensure that a configuration is really needed.

[lcswillems]

Yes, agree. The best is to have good defaults. I was just sharing what I have currently.

[igortas]

@Conaclos How I can automatically sort on format or check command?
Currently I enabled sorting on two places, in the settings.json file and also in rome.json

"editor.codeActionsOnSave": {
   "source.organizeImports.rome": true,
 },

 "organizeImports": {
   "enabled": true
 }

[Conaclos]

You can use rome check --apply-unsafe. Be aware that this also applies the unsafe fixes of the other lint rules. Otherwise, you can use the Rome LSP, an "organize imports" code action is available.

[JP250552]

This proposal looks nice and it would be great to extend it a bit further and allow for a space between the import group.

import pkg1 from "pkg1"
import pkg2 from "pkg2"

import { x } from "./x.js"

[jpike88]

Would be good to extend it even further, by treating alias imported via the 'paths' property as a seperate grouping

import extLib from 'extLib';

import { whatever } from '@server/blah';

import { x } from './x.js';

[ematipico]

Lines among imports have a meaning, so it's unlikely that we will add lines intentionally during the formatting.

[ematipico]

The next release - out soon - will have this implemented.

[lcswillems]

Yes!! Really really impatient! Is there an ETA for this release?