Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Argument of type '{}' is not assignable to parameter of type 'never' | Interferency of property and component names #3374

Closed
evgenii-code opened this issue Jul 6, 2023 · 9 comments
Labels
bug Something isn't working good reproduction ✨ This issue provides a good reproduction, we will be able to investigate it first

Comments

@evgenii-code
Copy link

After updating Volar to version v1.8.4, I got an error related to the interferency of property and component names.

Argument of type '{ class: string; }' is not assignable to parameter of type 'never'
Image of the error

image

This happens when I use the property name almost the same as the component name. despite the casing

Code of the components:

Parent
<template>
  <div>
    <foo-bar class="class" />
  </div>
</template>

<script lang="ts">
import { defineComponent } from 'vue'
import FooBar from '~/components/FooBar.vue'

export default defineComponent({
  name: 'SameComponent',

  components: {
    FooBar,
  },

  props: {
    fooBar: { // Almost the same name as component's name
      type: Boolean,
      default: false,
    },
  },
})
</script>
Child
<template>
  <div>Foo Bar</div>
</template>

<script lang="ts">
import { defineComponent } from 'vue'

export default defineComponent({
  name: 'FooBar',
})
</script>

Versions:
node v16.17.1
vue 2.7.10
nuxt 2.15.8
volar v1.8.4 - error
volar v1.8.3 - without error

Minimal repo
https://github.com/evgenii-code/volar-test/tree/naming-conflict

@rchl
Copy link
Collaborator

rchl commented Jul 6, 2023

Appears to be caused by #3350

@rchl rchl added bug Something isn't working good reproduction ✨ This issue provides a good reproduction, we will be able to investigate it first labels Jul 6, 2023
@rchl
Copy link
Collaborator

rchl commented Jul 26, 2023

It looks like with the Options API, local properties can not override global or local components unlike with script setup where local variables override global components.

In a script setup with a global HeaderTest component and a local variable HeaderTest, the local variable overrides global component:

<script setup lang="ts">
import { defineComponent } from 'vue';
const HeaderTest = defineComponent({ render() { return 'yyy'}})
</script>

<template>
    <HeaderTest />
</template>

(Renders 'yyy')

With the Options API, even local components definition doesn't override global component:

<template>
    <HeaderTest />
</template>

<script lang="ts">
import { defineComponent } from 'vue';

const HeaderTest = defineComponent({ render() { return 'yyy'}})

export default defineComponent({
    components: {
        HeaderTest
    },
})
</script>

(Renders contents of the global HeaderTest component.)

So perhaps the logic introduced in #3350 needs to consider the script type and apply different logic there. If that is even possible (not sure if it's possible to distinguish those cases).

@Sn0wCrack
Copy link

I seem to be encountering a similar issue now as of the 1.8.12 release when using the Options API.

Release 1.8.11 and prior seem to work fine for me.

I believe the issue may be related to this PR: https://github.com/vuejs/language-tools/pull/3565/files

As enabling strictTemplates within my tsconfig.json seems to remove these errors.

@so1ve
Copy link
Member

so1ve commented Sep 21, 2023

@Sn0wCrack Could you please provide a minimal reproduction then open a new issue?

@Sn0wCrack
Copy link

I'll try and see if I can replicate the specific issue and provide you with some code for it, currently trying narrow down what specific cause of it and am having trouble actually replicating it in a fresh project.

I've attached the exact output I receive of vue-tsc and my related tsconfig.json files:
vue-tsc-issue.zip

When I place some of these components that produce this error into similarly setup projects (same dependencies, typescript version and vue-tsc version), I don't end up receiving these errors from vue-tsc, so my assumption is this is related to some kind of configuration difference.

I'll keep trying on my end to replicate and see what I come up with.

If it makes any difference, this is a Laravel project using Inertia.js and is compiled using Vite.

@IGx89
Copy link

IGx89 commented Sep 29, 2023

Also just ran into this myself when updating vue-tsc to 1.8.15, on a custom component and RouterLink. Couldn't turn on strictTemplates (didn't like data-testid attributes), but downgrading to 1.8.11 did the trick.

@gnut-neygun
Copy link

Also just ran into this myself when updating vue-tsc to 1.8.15, on a custom component and RouterLink. Couldn't turn on strictTemplates (didn't like data-testid attributes), but downgrading to 1.8.11 did the trick.

I have the same problem with data-testid from Cypress after turning strictTemplates, but you can add dataAttributes: ["data-testid"] under vueCompilerOptions in tsconfig.json to fix the error.

@gnut-neygun
Copy link

@Sn0wCrack Could you please provide a minimal reproduction then open a new issue?

Very strangely enough I can also not reproduce this issue on a fres project. But it's still present on 1.8.27 (and fixed by turning on strictTemplates)

johnsoncodehk added a commit that referenced this issue May 13, 2024
@johnsoncodehk
Copy link
Member

Closed due to unable to reproduce in latest version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good reproduction ✨ This issue provides a good reproduction, we will be able to investigate it first
Projects
None yet
Development

No branches or pull requests

7 participants