10.0.0 is inconsistent with type imports

[MrHands]

I have the following block of imports:

// base-character-data-model.ts
import {
	type ECharacterStat,
	type TCharacterStatString,
	CharacterStatValues,
	ECharacterMood,
	ELocation,
} from '~enums';

Running npx eslint --fix base-character-data-model.ts reshuffles the imports:

import {
	CharacterStatValues,
	ECharacterMood,
	type ECharacterStat,
	ELocation,
	type TCharacterStatString,
} from '~enums';

But the ESLint plugin for Visual Studio Code flags this ordering as an error:

Run autofix to sort these imports!eslintsimple-import-sort/imports

And indeed, saving the file in Visual Studio Code automatically sorts the import block back to the previous ordering. Looking at the diff between 9.0.0 and 10.0.0, I do not see an option to sort the types before other imports. As a result, I am unable to upgrade your plugin to 10.0.0 for my codebase.

Here's the relevant section of my .eslintrc.js:

// https://mysticatea.github.io/eslint-plugin-eslint-comments/rules/

const importsRules = {
	// mark an import as a type-only import by adding a "kind" marker to the import
	'import/consistent-type-specifier-style': ['error', 'prefer-inline'],

	// Report if there is no default export in the imported module if one is requested
	'import/default': 'error',

	// Reports funny business with exports, like repeated exports of names or defaults
	'import/export': 'error',

	// Enforce that all exports are declared at the bottom of the file
	'import/exports-last': 'error',

	// Ensure consistent use of file extension within the import path
	'import/extensions': [
		'error',
		{
			css: 'always',
			js: 'never',
			json: 'always',
			scss: 'always',
			ts: 'never',
		},
	],

	// Report any imports that come after non-import statements
	'import/first': 'error',

	// Reports when named exports are not grouped together in a single export declaration
	'import/group-exports': 'error',

	// Enforces having one or more empty lines after the last top-level import statement
	'import/newline-after-import': ['error', { count: 1 }],

	// Forbid import of modules using absolute paths
	'import/no-absolute-path': 'error',

	// Disallow AMD require/define
	'import/no-amd': 'error',

	// Disallow require()
	'import/no-commonjs': 'off',

	// Forbid require() calls with expressions
	'import/no-dynamic-require': 'error',

	// Reports the use of empty named import blocks
	'import/no-empty-named-blocks': 'error',

	// No Node.js builtin modules
	'import/no-nodejs-modules': 'off',

	// Ensures an imported module can be resolved to a module on the local filesystem
	'import/no-unresolved': [
		'error',
		{
			ignore: ['~\\w+', '\\$\\w+', '^tsparticles-plugin-emitters/types'],
		},
	],

	// Forbid Webpack loader syntax in imports
	'import/no-webpack-loader-syntax': 'error',

	// Enforce a convention in module import order
	'import/order': 'off',

	// When there is only a single export from a module, prefer using default export over named
	// export
	'import/prefer-default-export': 'off',

	// Enforce sorted import declarations within modules
	'sort-imports': 'off',

	// Easy autofixable import sorting
	'simple-import-sort/imports': 'error',
	'simple-import-sort/exports': 'error',
};

Thank you for your hard work on this amazing plugin. Please let me know if you have a workaround.

[lydell]

Hi!

The problem you need to solve is to make sure that running eslint on the command line and ESLint within VSCode results in the same output – that both of them are using the exact same versions of ESLint, plugins and configs.

Sometimes, restarting VSCode is all that’s needed.

[lydell]

Just to clarify: Most likely, the CLI is using the latest version of eslint-plugin-simple-import-sort, while VSCode is using the previous version for some reason.

[MrHands]

Hey Simon, thanks for getting back to me. You were right; I had to restart Visual Studio Code to get everything working correctly. I was a bit grumpy about the import order being changed; I would have preferred that behavior behind a flag. My project uses code generation for many of my imports, so I had to change that to match the new sorting behavior. Luckily, this did not turn out to be as big of a deal as I had feared, and I'm now happily purring along on 10.0.0.