Detect unknown/undefined prop usage

[IceBlizz6]

This is a proposal for enhancing vue-tsc

Example:

<MyComponent
    :propThatDoesNotExist="42"
/>

When running npx vue-tsc --noEmit i want it to detect that propThatDoesNotExist is not presently defined in myComponent.
This could produce a warning or error.

Feature like this currently exists in TS files.
When trying to edit fields that is not defined in some typescript class it will output:
Property 'xxx' does not exist on type 'MyClass'.

This would be very helpful for Vue developers when renaming props or performs refactoring or git rebases as looking through the code manually can be tedious.

[johnsoncodehk]

This is intentional behavior as this is often used in css selectors.

I'll explore add a option in vueCompilerOptions to change this behavior.

[IceBlizz6]

@johnsoncodehk thanks
would be great to have.
Having to opt in through some configuration is fine.

[sapphi-red]

I also think it is great to have this feature.
IMO data-* and aria-* can be ignored even if it is not used.

[xiaoxiangmoe]

https://www.typescriptlang.org/docs/handbook/jsx.html#attribute-type-checking
Note: If an attribute name is not a valid JS identifier (like a data-* attribute), it is not considered to be an error if it is not found in the element attributes type.

But it seems that vue always treat attribute data-foo as dataFoo

[IceBlizz6]

It may be more appropriate to handle this case by giving a warning rather than an error.
The proposed solution is to add option in vueCompilerOptions so maybe users can select option there for themselves of how severe they want to treat this issue, including the possiblity of disabling the check itself

[eladcandroid]

@johnsoncodehk Do you have any plan for adding that? Maybe we can check with
https://vuejs.org/api/options-misc.html#inheritattrs

[johnsoncodehk]

In 0.36, custom / unknown attrs types behavior handle responsibility will transfer to developer.

• Expand custom attrs example

<template>
    <div myprop="a">
</template>

// env.d.ts
declare module '@vue/runtime-dom' {
    interface HTMLAttributes {
        myprop: string
    }
}

export { }

• Allow any attrs

// env.d.ts

// for native html elements
declare module '@vue/runtime-dom' {
    interface HTMLAttributes {
        [key: string]: any
    }
    interface SVGAttributes {
        [key: string]: any
    }
}

// for vue components
declare module '@vue/runtime-core' {
    interface AllowedComponentProps {
        [key: string]: any
    }
}

export { }

[lohchab]

@johnsoncodehk Thankyou for mentioning that here. Suddenly today my Visual Studio Code started giving 'property does not exist on type' warnings for all the custom attributes starting with 'data-*' like this <h1 data-icon="check">Test</h1> after adding the code in env.d.ts for allow any attrs it solved the issue.

declare module '@vue/runtime-dom' {
interface HTMLAttributes {
[key: string]: any
}
}

export { }

[lohchab]

@johnsoncodehk Since this change regarding unknown properties. I am also getting this error on a V-Calendar Components v-model value before this it was fine. I am newbie and don't have any idea how I can omit this warning.

[ildan95]

I also think it is great to have this feature. IMO data-* and aria-* can be ignored even if it is not used.

Hello. How to enable ignoring this case?

[Fuzzyma]

This change is bonkers! How do volar check where this attribute that I passed on purpose ends up? Does it just "assumes" it is the root element of the template? But even that doesn't work properly. Vue has an attribute fallthrough on purpose and this change makes vue-tsc crash on basically every component where I use attribute fallthrough (which I use A LOT).

This feature should be opt-in and not opt-out.

How can I disable this?

[lohchab]

I also think it is great to have this feature. IMO data-* and aria-* can be ignored even if it is not used.

Hello. How to enable ignoring this case?

@ildan95 You can add the below listed code in your env.d.ts file and it will allow you to use the data-* and aria-* properties.

// env.d.ts
declare module '@vue/runtime-dom' {
    interface HTMLAttributes {
        [key: string]: any
    }
}

export { }

[Fuzzyma]

@johnsoncodehk your solution does not work for components. I cant even pass an id attribute to a component

[lohchab]

@Fuzzyma His solution has worked for me and now I am able to add any properties and Visual Studio Code dont show up any warnings for them just like earlier.

Add this to your env.d.ts file in your Project Root Folder.

// env.d.ts
declare module '@vue/runtime-dom' {
    interface HTMLAttributes {
        [key: string]: any
    }
}

export { }

[Harkonnen13]

@lohchab I can't make it work on components

LIke on native elements it works fine, but what about component attributes? I have VInput component which is just a wrapper around native input. SO i have to describe ALL native attributes in props to apply them?

[Fuzzyma]

exactly. it might work for html elements but attribute fallthrough for components doesn't work at all

[lohchab]

@lohchab I can't make it work on components

LIke on native components it works fine, but what about component attributes? I have VInput component which is just a wrapper around native input. SO i have to describe ALL native attributes in props to apply them?

I got you. Yes, you are right I can confirm its is not working. Its only working for HTML Elements.

For a temporary workaround till the time there's a no solution to this my recommendation is that you switch your Volar Extension Version to the '0.35.2' and Restart the Visual Studio Code.

[Fuzzyma]

Until this is fixed, the proper solution is to revert this feature or hide it behind a flag and release a new version because in the current state it's just plane broken

[johnsoncodehk]

@lohchab I can't make it work on components

LIke on native elements it works fine, but what about component attributes? I have VInput component which is just a wrapper around native input. SO i have to describe ALL native attributes in props to apply them?

You should use AllowedComponentProps interface, please check updated example code.

[lohchab]

// env.d.ts

// for native html elements
declare module '@vue/runtime-dom' {
    interface HTMLAttributes {
        [key: string]: any
    }
}

// for vue components
declare module '@vue/runtime-core' {
    interface AllowedComponentProps {
        [key: string]: any
    }
}

export { }

Thankyou @johnsoncodehk I can confirm adding this code to env.d.ts file has solved the unknown property problems for both HTML and Vue Component Elements. Keep up the good work. We all appreciate what you are doing on Volar!

[keithbrink]

I agree that this type of strict linting should be opt-in, fallthrough attributes are a common use case with Vue and the default configuration of Volar should just work with the examples from the Vue docs.

[henribru]

This isn't just about fallthrough either, as shown in #1383 this is causing errors for many completely standard HTML attributes directly on the elements. It seems unreasonable requiring people to add custom declaration files to avoid that

[Harkonnen13]

Is it possible to make an option like mode="strict" to change default behavior? I mean, props existence check looks like an edge case than something default. Because everything that not described in props are custom attributes, that's vue default behavior

[rffl]

In 0.36, custom / unknown attrs types behavior handle responsibility will transfer to developer.

• Expand custom attrs example

<template>
    <div myprop="a">
</template>

// env.d.ts
declare module '@vue/runtime-dom' {
    interface HTMLAttributes {
        myprop: string
    }
}

export { }

• Allow any attrs

// env.d.ts

// for native html elements
declare module '@vue/runtime-dom' {
    interface HTMLAttributes {
        [key: string]: any
    }
}

// for vue components
declare module '@vue/runtime-core' {
    interface AllowedComponentProps {
        [key: string]: any
    }
}

export { }

It didn't work unfortunately as the project that I'm working on at the moment is using pure JavaScript without TypeScript, and the errors always appear.

[SegaraRai]

Thanks to this feature, I noticed that the Vuetify property names had been updated and was able to correct them. :)
However, it took some work to resolve the issue. FYI:

• I had to explicitly add @vue/runtime-core and @vue/runtime-dom to dependencies (probably because I use pnpm).
• The .d.ts file must be separate from the file defining the vite's ImportMetaEnv (if any).

For now, I use the following definition in env2.d.ts.

import '@vue/runtime-core';
import '@vue/runtime-dom';

// for vue components
declare module '@vue/runtime-core' {
  export interface AllowedComponentProps {
    [key: string]: any;
  }
}

// for native html elements
declare module '@vue/runtime-dom' {
  export interface HTMLAttributes {
    // allow any data-* attr
    [key: `data${string}`]: string;
  }
}

export {};

Complex libraries such as Vuetify do not always have all properties defined (especially if they are passed through), and users will end up having to disable the feature completely.
The ideal solution would be for the type definitions of Vuetify components to be updated, but this is not always done quickly.
It seems difficult to use without at least a way to define additional attributes for individual components.

[johnsoncodehk]

In v0.36.1 this behavior is control by vueCompilerOptions.experimentalSuppressUnknownJsxPropertyErrors and default enabled, if you want report unknown props you need config:

// tsconfig.json
{
  "vueCompilerOptions": {
    "experimentalSuppressUnknownJsxPropertyErrors": false
  }
}

If you see how volar hacking JSX types to ignore unknown prop errors, you may want to disable it. (This shouldn't be part of volar's control)

https://github.com/johnsoncodehk/volar/blob/104af79387fec40ec3c9e82299f1258f1947673e/packages/vue-typescript/src/typescriptRuntime.ts#L282-L290

[TheDutchCoder]

Can you make this disabled by default instead?

I still don't understand what the real point is, as this change breaks totally valid code all over the place for known attributes like all aria attributes.

I'm sure there's good intentions here, but people (especially new users) will have no idea what is going on when their data- attributes are throwing errors suddenly.

[johnsoncodehk]

@TheDutchCoder Maybe there are some misunderstood, "SuppressUnknownJsxPropertyErrors" mean ignore unknown prop errors, I think you don't want disabled it by default.

[TheDutchCoder]

Okay I'll give it a spin later.

Just to clarify: data- and aria- attributes are not unknown jsx attributes/properties.

So regardless of the setting, these should never throw errors, which was the original issue.

[Fuzzyma]

I can confirm that the update fixes all issues. The feature is now opt-in as described above. Thank you for the quick fix!

[lucas-labs]

As @TheDutchCoder said, data-* and aria-* are not unknown attributes, specially on "plain" html elements. They are standard W3C recommendations. The following piece of code is valid html and it should not throw an error regardless of the setting:

<template>
    <input aria-describedby="emailHelp">
    <p id="emailHelp">aria help...</p> 
</template>

[johnsoncodehk]

As @TheDutchCoder said, data-* and aria-* are not unknown attributes, specially on "plain" html elements. They are standard W3C recommendations. The following piece of code is valid html and it should not throw an error regardless of the setting:

<template>
    <input aria-describedby="emailHelp">
    <p id="emailHelp">aria help...</p> 
</template>

Fix by ba2835f.

[TheDutchCoder]

@johnsoncodehk
I still can't get this to work properly.

If I disable experimentalSuppressUnknownJsxPropertyErrors I still get errors thrown for data- and aria- attributes.
If I enable it, invalid attributes don't throw errors at all.

Example:
The data-test-id attribute should not throw an error, but the thisisnotvalid attribute should:

Edit: maybe this isn't released yet?
I'll downgrade in the meantime again

[Fuzzyma]

@TheDutchCoder if you don't have the option set, it's on by default. Which means volar behaves as if this feature wasn't enabled at all (its a feature flag). Nothing else was changed afaik.

[TheDutchCoder]

This still doesn't solve anything.

Setting this to true means that unknown attributes (e.g. foo="bar") will go unchecked.
Setting this to false means that known attributes throw errors (e.g data-foo or aria-disabled).

[IceBlizz6]

I am unable to get this to work with the latest version.
vue-tsc 0.38.3 will report errors of unknown props like expected.
later versions reports no errors, even when it should.
I have tested 0.38.4, 0.38.5, 0.39.4

Can anyone confirm that this feature still works as expected?
if not then i suspect it broke in 0.38.4

[johnsoncodehk]

@IceBlizz6 You should use vueCompilerOptions.strictTemplates, see https://github.com/johnsoncodehk/volar/blob/master/CHANGELOG.md#0384-2022711.