Major formatting issue with Typescript imports (reopen)

[rhnatiuk]

It seems that the problem persists in the latest version (2.0.8?) (i.e., https://github.com/aljazsim/vs-code-typescript-code-organizer/issues/93 did not fix the problem).

Following imports:

import type { A } from "@c/api";
import { B } from "@c/api";

are still wrongly "formatted" as:

import { A, B } from "@c/api";

[type is removed for A] despite in tsco.json all import formatting is disabled:

	"imports": {
		"removeUnusedImports": false,
		"sortImportsBySource": false,
		"sortImportsByName": false,
		"groupImportsBySource": false,
		"separateImportGroups": false,
		"quote": "double"
	},

The expected fix would be to either format type {xxx} imports properly (preferred), or disable formatting for imports if config says so.

[acousins72]

I can confirm this behaviour I have done a quick test of 2.0.8 and with the following in the file

/*******************************************************************************
 * Copyright (c) 2025. My Corporation.                                                                    
 ******************************************************************************/
import { TokenEnum } from "./TokenEnum.ts";
import type { IType2 } from "./IType2.ts";
import type { IType1 } from "./IType1.ts";
import { convertToType1 } from "./IType2.ts";
import { createWorker } from "./helpers/WorkerCreator";

the result of organizing it is

import { IType1 } from "./IType1.ts";
import { IType2, convertToType1 } from "./IType2.ts";
/*******************************************************************************
 * Copyright (c) 2025. My Corporation.                                                                    
 ******************************************************************************/
import { TokenEnum } from "./TokenEnum.ts";
import { createWorker } from "./helpers/WorkerCreator";

As you can see it still drops the type. It also seems to be moving the header comment but that may be a separate issue.

[rhnatiuk]

@aljazsim , any hope to see this problem fixed?

[rhnatiuk]

@aljazsim ?

[aljazsim]

I've fixed the issue with type only import, please update to version 2.0.9. With the file header what happens is the comment is considered to be the leading comment of the first import by AST, hence it moves down to keep with the first import. It's a separate issue from type only import. I'm not sure how to properly fix the issue with the comment though. Always treat the first comment of an import as the file header? But what if it's an actual comment and should belong with the first import? Or maybe just treat /** ... */ comments as file headers? Is there a standard how file headers should be formatted?

[rhnatiuk]

Okay, it seems to work now (at least the imports don't miss type anymore). Thanks!

[acousins72]

Cool types are working for me now too, Thanks

As for the comment, I kinda assumed thats how they were being handled and I don't think that you will be able to find a way to detect it being a header , to many people/companies have their own standards on it. The only thing that I can see is having an option to treat the first comment as a header. I'm working on a project with a lot files that I'm organizing as I do code changes so let me know if you need any help testing.

For now it is not breaking the code and I can look out for it (or it will be caught in code review) but I'm hoping that you can fix it so I don't have to. :)

Thanks for all your work on this tool

[aljazsim]

Thanks Andy! I was thinking if there's a comment on the first element (could be an Import or a Class/Interface/Type), and it is a multiline comment separated by an empty line, that could be considered a file header and should be left on top

[acousins72]

That would be good for most cases but I'm dealing with a code base that was implemented by many developers that all thought they knew best and as such there is no consistency with any formatting let alone things like the header having an empty line after it. That being said implementing that rule will take care of a majority of my cases and the few it doesn't I should be able to deal with and be compliant from then on.

[aljazsim]

Awesome, I'll see what can be done!

[aljazsim]

I've added support for handling file header docs, please update to version 2.0.10 and give it a try. Header should be at least 3 lines long and can be a comment like:

/*
 * This is a header.
 */

or a comment like:

//
// This is a header.
//