Unexpected import-x/sort issue in >=3.8

[iCrawl]

Somewhere starting from 3.7.0 there seems to be some kind of bug introduced or at least a breaking change in behavior reading custom tsconfig paths.

v3.7.0...master

Previous result:

No errors.

After 3.8:

No change in userland code at all.

This obviously leads to errors where the visual editor, whether that be cursor, visual studio code or whatever wants to move those lines. But when I then try to commit and run the CLI it will complain because they shouldn't be moved around. This didn't happen in 3.7

The tsconfig paths are relatively simple as well:

...
		"paths": {
			"@/*": ["./src/*"]
		}
	},
	"include": [
		"src/**/*.ts",
		"src/**/*.tsx",
		"src/**/*.js",
		"src/**/*.jsx",
		"src/**/*.cjs",
		"src/**/*.mjs",
		"next-env.d.ts",
		".next/types/**/*.ts"
	],
...

Temporary fix for me: Downgrade and pin to 3.7.

[carlocorradini]

Can you retry when PR #352 is merged? Thanks 🙏

[carlocorradini]

Furthermore, import/order supports extra configuration parameters.
Using type-graphql as an example, we instruct eslint that any imports beginning with @ belong to the internal group and should be placed before.
See https://github.com/MichalLytek/type-graphql/blob/562e1da25ddd76d94d1921a28619d233a88d86bd/.eslintrc#L59 for a full example

[iCrawl]

Yes, great. The 3.8.1 release solved this issue!

Further follow-up question if you don't mind:

My current rule is set up like this:

	"import-x/order": [
		2,
		{
			alphabetize: {
				caseInsensitive: false,
				order: "asc",
			},
			groups: ["builtin", "external", "internal", "parent", "sibling", "index"],
			"newlines-between": "never",
		},
	],

Mainly to avoid hard-coding any specific "symbols" since its a shared preset. And I therefore would expect any "relative" imports to naturally come after whatever symbols I choose in my tsconfig paths, is this assumption correct?

[carlocorradini]

@iCrawl Personally, I'm not sure how import-x handles this, but I believe we need to add the pathGroups configuration option to guide the plugin.
Because it is used in conjunction with this resolver, and TypeScript paths are resolved with absolute paths, there may be false positives.
This is my guess, so take it with a grain of salt!

[iCrawl]

Alright, thanks!