Imports Sorting in the CLI

[leops]

Starting with version 11.0.0, Rome will ship with an experimental imports sorting feature. For the initial implementation this new feature is only accessible through the "Organize Imports" code actions in editors, but we want to eventually make it available through the CLI. Exactly how that will works is still open to discussion though as all the ways we could perform this integration have pros and cons:

Run in rome format

Pros

Prettier has widely used plugins for sorting imports, making it likely most users would expect this action to run along with the formatter.

Cons

We've generally avoided introducing "side-effects" to the formatter, but re-ordering imports can change the semantics of the code.

Run in rome check

Pros

The "Organize Imports" action is implemented through the same Analyzer infrastructure as the linter, so the integration effort should be minimal. If we go in this direction we may even turn the action into a style/useSortedImports lint rule and integrate it fully into the linter.

Cons

Users might find this confusing since we would have both a linter and formatter, with the feature of "formatting" split between the two. Specifically for the point of "turning the action into a full lint rule", this would mean the in-editor "Organize Imports" action would stop working it the linter (or rule) is disabled. If we don't go with a lint rule, this also asks the question of where we should put the configuration for the action in the rome.json file (since it wouldn't make sense to put it under the linter section).

Run in rome sort-imports

This new command would also be run by rome ci, in the same way format and check are already

Pros

This clearly separates the "Imports Sorting" feature from the "Formatting" and "Linting" on the CLI, in the same way they are separated in the editor and internally in the Rome codebase.

Cons

Introduce a very specialized command to the CLI that's possibly hard to discover and requires special handling to integrate into existing workflows. Doing it this way would also probably warrant creating a sortImports section at the root of the rome.json file for configuring this command, which once again seems overly specialized and hard to discover.

[nstepien]

My vote is on integrating it as part of the formatter.
I don't want to see squiggles for unsorted imports.

We've generally avoided introducing "side-effects" to the formatter, but re-ordering imports can change the semantics of the code.

Doesn't that apply anyway, whether it's part of the formatter, the linter, or a separate command?
Just doesn't seem specific to it being part of the formatter.

Configuration for it could be something like this

{
  "formatter": {
    "//": "disabled",
    "organizeImports": false,

    "//": "enabled with default config",
    "organizeImports": true,

    "//": "enabled with custom config",
    "organizeImports": { ... },
  },

[ematipico]

@leops

Users might find this confusing since we would have both a linter and formatter, with the feature of "formatting" split between the two.

Could you please expand on this? Why would the feature be split in two?

---

I think sorting imports in JavaScript is not necessarily something related to the formatter, I would say it depends on where a developer comes from.

For example, I come from some experience where sorting imports is part of a linter/analyzer: https://github.com/lydell/eslint-plugin-simple-import-sort
Some other developers, like Rust developers, might see the sorting of imports under the formatter because Rust is a side-effect-free language. Python developers might differ - I am just guessing - because python is a side-effect language.

I also come from an experience where the order of the imports matters, for example, when using webpack, CSS modules, and importing CSS inside components. Very often, webpack couldn't "guess" the correct order of CSS when bundling for production (this problem might not exist inside rome).

I would personally prefer having the sorting under the formatter umbrella, but ultimately, I think the safest bet, in the long run, is to have it under the analyzer (rome check command) umbrella.

Here are some of the motivations:

• JavaScript is a side-effect language (and so many other languages);
• in a world where components are tight to CSS stylesheets, the order of imports becomes even trickier and more critical;
• the formatter is not aware of mixed imports (CSS, fonts, JS, etc.) and the side effects of the project;
• to understand the correct order of imports in a web world, we might need to analyze even the whole project;

As for the configuration, I think it needs to go under the "javascript" section because modules have different concepts/semantics in other languages. For example, CSS might not need a configuration... or it might need a different configuration. Same story for other languages.

{
	"javascript": {
		"organizeImports": {}
	}
}

I don't know if the imports should go under a lint rule... I don't have strong feelings. But I would prefer to have it a separate task of the rome check command, and ultimately we could have things like this:

rome check --organize-imports-enabled=false

{

	"organizeImports": {
		"enabled": false
	},
	"javascript": {
		"organizeImports": {
			// I am inventing stuff here
			"order": ["foo", "bar", "etc."]
		}
	},
	"css": {
		"organizeImports": {
			// I am inventing stuff here
			"type": "natural"
		}
	}
}

This is mainly because we already know that check is a command meant to run different types of tasks, and sorting imports can be one of those.

[jeysal]

Agree with linter because of side effects and it being much more flexible than the formatter. The formatter is supposed to be deterministic based on the code string and a few config options. The analyzer may be able to take into account further context such as a sideEffects: true declaration, or even looking at the other files to statically check whether they are guaranteed side-effect free.

[Conaclos]

Just worth to mention: The bundler setting sideEffect: false in package.json allows signaling that the project has side-effect-free ESM.

Moreover, bundler encourages users to use side-effect imports for avoiding to tree-shake mutating imports:

import "module-with-mutation" // is not tree-shaked
import { X } from "module-with-mutation" // may be tree-shaked

The order of side-effect imports should not be modified and could come first. Other imports could be freely reordered.

[ematipico]

That's exactly why I think the analyzer should be the best place to sort the imports.

I wish sideEffects was an official property defined by npm, but it's not 😢 . It's been introduced by webpack as unofficial field.

[jpike88]

this is useful, I would run this in addition part of my prettier checks (but ONLY this part of the Rome cli formatting-wise, I would use prettier for everything else), as the prettier 3rd party sort imports plugin isn't reliable enough.

[harrytran998]

https://github.com/trivago/prettier-plugin-sort-imports

Here are the things! I'm pretty satisfied with this lib. When using monorepo, our import looks messy after file scale-up business logic with multiple imported packages. So this lib is like the saver for us to format something we want!

The first stage should be the Js, ts, and TSX file extensions.

{
	"formatter": {
		"import": {
			"order": ["^@core/(.*)$", "^@server/(.*)$", "^@ui/(.*)$", "^[./]"],
			"insertSeparation": boolean,
			"parserPlugins": {
				"vue": {...},
				"astro": {...},
				"svelte": {...},
			}
			....
		},
	}
}

@leops Hope you guys add this feature to the backlog soon 😆. Always favor ROME!