[import/extensions] Suffixes in file names

[anton-johansson]

Hey! I've embraced a file name convention where the files are suffixed depending on the kind of export. For example:

• my-service.class.ts
• providers.enum.ts
• token.const.ts
• editable.interface.ts

I'm having a hard time tweaking import/extensions to support this. I want to exclude .ts from my imports, so naturally that means "ts": "never". However, I do get errors like:

Unexpected use of file extension "class" for "~/shared/my-package/my-service.class" (import/extensions).

Adding "class": "always" doesn't help either.

Any ideas? I assume the ideal scenario would be to treat the "extension" as only the last part of the file name, but I also assume that it's hard for the plugin to see that (I guess it only looks on the actual import statement?).

[ljharb]

Since there’s only one extension, and your odd convention isn’t an extension, I’d expect it to have no impact on the rule.

In other words, this is a bug with the rule that should be fixed (altho I’d suggest dropping this convention).

A PR or link to a branch with failing test cases would be most helpful.

[olsonpm]

I thought I ran into this however found my path to the dependency was incorrect. Here was the resulting behavior

file structure

/run.js
/some.dep.js

// run.js
require('./some.dep')
require('./some.dep2')

$ npx eslint run.js

/path/to/run.js
  2:9  error  Unexpected use of file extension "dep2" for "./some.dep2"  import/extensions

✖ 1 problem (1 error, 0 warnings)

this error is further clarified with "import/no-unresolved", so I don't know it's a bug in the plugin.

[ljharb]

Yeah, after reviewing this again, I think this isn't a bug, this is just the consequence of using dots in a file while also omitting extensions in the specifier.

This isn't a good convention - filenames should only have zero or one dots, and the extension is whatever's after the dot.