Eslint-plugin-import: Named code blocks confuse relative import paths

[Conduitry]

Hey there! I'm the author of a processor plugin that produces named code blocks, which are confusing this plugin, because the new virtual path for the js files is now one additional layer down.

I'm not sure whether this plugin is something that was considered when named code blocks were added in ESLint 6, or whose responsibility it's going to be to fix this. I'll gladly make changes to my plugin if that's what it takes, but right now I don't know what those would be.

Thanks!

See also:

• The issue on my plugin: https://github.com/sveltejs/eslint-plugin-svelte3/issues/36
• My question on the ESLint Gitter: https://gitter.im/eslint/eslint?at=5d2a5c01eab6cd7763632e20

[ljharb]

What are named code blocks? Is it a JavaScript feature I’m unaware of?

[Conduitry]

It's a new feature with processors in ESLint 6 - https://eslint.org/docs/user-guide/configuring#specifying-processor

[ljharb]

So these are nonexistent virtual files that are different from the only previous instance of these, which is “stdin” - looks like this is something eslint v6 has forced every plugin to potentially handle - since my assumption is that a plugin’s visitors get called on this code block as if it was a normal file.

One option is to bail out early on every cross-file rule; but a better one would be to treat them like normal files. A PR to fix this, with test cases, would be appreciated.

[Conduitry]

I'm not sure how a plugin would be able to distinguish between a virtual named block file, and a file that's inside a folder whose name simply contains a .. Should it just check whether the current 'file' actually exists in the filesystem? Is that something that would happen here?

[ljharb]

eslint itself may provide that information in the file’s context; I’m not sure yet.

[Conduitry]

I don't believe the necessary information is currently available. Opened https://github.com/eslint/eslint/issues/11989