Closed maxmilton closed 5 years ago
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.
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.
Also created an issue on eslint-plugin-import and linked back here.
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.
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.
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.
We now have the
svelte3/named-blocks
option (fixed https://github.com/sveltejs/eslint-plugin-svelte3/issues/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 theeslint-plugin-import
package now think the file is nested a directory deeper than it really is.