feature request: enforce comments after last import

[TrigamDev]

At least personally, I often use a comment separator between imports and the rest of the file, especially when the file has a large number of imports. Having a rule to enforce this would be very helpful.

This could potentially conflict with newline-after-import, though. I can think of two ways to resolve this.

Solution 1

The separator comment must be placed either before or after the new lines enforced by newline-after-import . Whether the comment is placed before or after could potentially be configured with an option in the rule, or one could be chosen to be hardcoded with it not being configurable. This is a little clunky, however.

Example

Options

{
	"import/comment-after-import": [
		"warn",

		/* Whether to style as line comments,
		or a block comment. */
		// "line" | "block"
		"block",

		/* The content of the comment.
		Can be one string using \n, or an array of
		strings, one element representing a line. */
		// string | string[]
		"---------------",

		/* Whether the comment should be placed
		before or after the new lines enforced by
		newline-after-import. */
		// "before" | "after"
		"before"
	],

	"import/newline-after-import": [
		"warn",
		{
			count: 2
		}
	]
}

❌ Invalid

import foo from "bar"
import type { baz } from "quux"


console.log("Hello world!")

✅ Valid

import foo from "bar"
import type { baz } from "quux"
/* --------------- */


console.log("Hello world!")

Solution 2

Instead of adding a new comment-after-import rule, newline-after-import could be modified to enforce lines with specific content, not just empty lines. The rule would also have to be renamed to reflect this change.

Example

Options

{
	"import/lines-after-import": [
		"warn",
		{
			/* The lines that should be present after
			the last import.
			Can be one string using \n, or an array of
			strings, one element representing a line. */
			// string | string[]
			"lines": [
				"",
				"",
				"/* --------------- */",
				"",
				""
			]
		}
	]
}

❌ Invalid

import foo from "bar"
import type { baz } from "quux"


console.log("Hello world!")

✅ Valid

import foo from "bar"
import type { baz } from "quux"


/* --------------- */


console.log("Hello world!")

[ljharb]

I'm a bit confused why, in a world with syntax highlighting, a comment is helpful to differentiate between imports and regular code?

[TrigamDev]

I'm a bit confused why, in a world with syntax highlighting, a comment is helpful to differentiate between imports and regular code?

Sorry, didn't see the reply until now.
At least personally, I get a little overwhelmed when it comes to larger files, and having comment dividers to split up different sections helps a lot with this. It's not about telling what is and isn't imports, but visually breaking up the two into distinct sections.

[ljharb]

Have you considered that the problem there is "larger files" itself?

[TrigamDev]

By "larger", I more mean in relation to what I normally write, which tends to be on the small side (usually 500 lines or less). I usually keep things to the smaller end of that range, but sometimes it doesn't make sense to split the file into smaller ones.

Even aside from the utility, it's nice to have for aesthetic reasons.

[ludgerey]

I've never seen that in any real code. Why bother having this in a linter?

Personally I'd oppose having this in my code as well, because this comment has no value at all a side from visual effect.

I'd suggest picking an IDE that helps visualizing stuff like that better if you struggle with it @TrigamDev