Conversation
f8d4295 to
695424c
Compare
Signed-off-by: Ferdinand Thiessen <[email protected]>
Signed-off-by: Ferdinand Thiessen <[email protected]>
695424c to
6defee1
Compare
| 'import/resolver': { | ||
| typescript: true, | ||
| node: true, | ||
| }, |
There was a problem hiding this comment.
Haven't checked the docs, but can we disable resolving completely?
It seems unnecessary as bundler will check it anyway.
It has many places where it may break, like using <script setup>, especially in mixed environment.
There was a problem hiding this comment.
we can also use the next resolver which uses oxc-resolve which is the resolver used by Rolldown.
| // Already included in error rules, but we need to allow raw imports | ||
| 'import/no-unresolved': [ | ||
| 'error', | ||
| { | ||
| // Ignore Vite/Webpack query parameters, not supported by eslint-plugin-import | ||
| // https://github.com/import-js/eslint-plugin-import/issues/2562 | ||
| ignore: [ | ||
| '\\?raw$', | ||
| '\\?url$', | ||
| ], | ||
| }, | ||
| ], |
There was a problem hiding this comment.
For example, does this rule prevents errors that are not prevented by a bundler?
There was a problem hiding this comment.
depending on your config yes, e.g. if it otherwise will externalize the imports.
|
|
This is quite drastic, there are at least some good reasons for default exports:
|
can be easily excluded 👀 |
Then lets discuss this in a follow up similar to import ordering |
Just checked and yes, still the same issues. It is not possible to use it in mixed project (TS + JS). Looks like it tries to parse TS file as JS and dies on importing types. Or maybe we need to set the syntax for import plugin... |
|
Example: In export class AppData {
serverUrl = null // Line 19 <-----In try {
return require(`@global-styles/core/img/filetypes/${icon}.svg`)
} catch { // Line 58 <-----
return undefined
}In if (error.response?.status === 401) { // Line 60 <---- |
Signed-off-by: Grigorii K. Shartsev <[email protected]>
|
I've pushed a commit to reset it back to Alternative - set such options after |
|
Another problem: on import NcRichText from '@nextcloud/vue/components/NcRichText'because we export export default NcRichText
export {
NcRichText,
NcReferenceList,
NcReferenceWidget,
NcReferencePicker,
NcReferencePickerModal,
NcSearch,
registerWidget,
renderWidget,
isWidgetRegistered,
NcCustomPickerRenderResult,
registerCustomPickerElement,
renderCustomPickerElement,
isCustomPickerElementRegistered,
getLinkWithPicker,
anyLinkProviderId,
getProvider,
getProviders,
sortProviders,
searchProvider,
}So the plugin wants to import it: import { NcRichText } from '@nextcloud/vue/components/NcRichText'
// or
import NcRichTextComponent from '@nextcloud/vue/components/NcRichText' |
|
And another one: <script lang="ts">
export default {
inheritAttrs: false,
}
</script>
<script setup lang="ts">
import { ref } from 'vue'
const flag = ref(false)
</script>fails with And, what is awful, <script setup lang="ts">
import { ref } from 'vue'
export default {
inheritAttrs: false,
}
const flag = ref(false)
</script>PS: This is fine: <script setup lang="ts">
import { ref } from 'vue'
const flag = ref(false)
</script>
<script lang="ts">
export default {
inheritAttrs: false,
}
</script> |
|
And this is ruined completely. <script setup lang="ts">
import { ref } from 'vue'
const flag = ref(false)
log(foo)
</script>
<script lang="ts">
import { Foo } from 'foo'
const foo = new Foo()
export default {
inheritAttrs: false,
}
</script> |
|
Proposal: disable At least TS checks it, and developers seem to follow this rule without linting. While issues with the rule are serious. |
|
|
🗑️ in favor of #981 |

Was also enabled in v8 of the config, so it was missing for now.
So this is the last thing for feature parity with v8.