Relative paths broken when named-blocks = true

[maxmilton]

We now have the svelte3/named-blocks option (fixed #22), which is amazing, thank you.

While adding it in my ESLint preset, I found relative import paths are reporting unresolved. Looks like because the file path is changed to *.svelte/*.js, rules from the eslint-plugin-import package now think the file is nested a directory deeper than it really is.

[Conduitry]

Huh. I'm not sure what can be done about this or whether this is something that the ESLint folks already thought about or what. If I'm using named blocks, I don't really have any control over its being down an additional level. I just tell ESLint I want to use the filename instance.js, say, and it constructs the new path from that, here. I'll have to ask the ESLint Gitter.

[Conduitry]

Asked the Gitter. I may also well need some help chasing this one down, as there are a few separate parties involved here, and I'm not sure who's going to end up being responsible for this.

[Conduitry]

Also created an issue on eslint-plugin-import and linked back here.

[maxmilton]

TBH I didn't realise named code blocks are a built-in feature of ESLint. It must not have been very prominent in the 6.0.0 changelogs.

Since it's a native part of ESLint it makes sense that eslint-plugin-import should be the place to fix this.

Not sure if there's anything else to do here. Feel free to close if you think that's appropriate.

[Conduitry]

Yeah, I think it makes sense to close this. I'm not sure what is going to happen in eslint-plugin-import exactly, but it does seem like it's their responsibility if they're going to support ESLint 6.

[Conduitry]

Added a note to https://github.com/sveltejs/eslint-plugin-svelte3/blob/master/OTHER_PLUGINS.md with a link to the eslint-plugin-import issue.