Error TS6133: '$props' | '$setup' | '$options' is declared but its value is never read
Version
3.2.16
Node version: 16.6.2 NPM version: 7.20.3 Webpack version 5.53.0
Reproduction link
https://github.com/iraklisg/vue-typescript
Steps to reproduce
I have the following SFC
<script lang=ts>
import { ref, defineComponent } from 'vue'
export default defineComponent({
name: "Foo",
props: {
myProp: {
type: String,
default: 'Hello'
}
},
setup(props) {
const msg = ref(props.myProp);
return { msg }
}
})
</script>
<template>
<h1>{{ msg }}</h1>
<input v-model="msg">
</template>
When I try to build my app I am getting the following errors
ERROR in /home/node/app/resources/js/components/ApplicationCreateForm.vue.ts(10,46)
TS6133: '$props' is declared but its value is never read.
ERROR in /home/node/app/resources/js/components/ApplicationCreateForm.vue.ts(10,46)
TS6133: '$setup' is declared but its value is never read.
My tsconfig
file is the following
{
"compilerOptions": {
// Project options
"lib": ["esnext", "dom"],
"removeComments": true,
"target": "esnext",
"jsx": "preserve",
// Strict checks
"strict": true,
"noImplicitAny": true,
"strictNullChecks": true,
// Linter checks
"noImplicitReturns": true,
"noUncheckedIndexedAccess": true,
"noUnusedLocals": true,
"noUnusedParameters": true, <--- this causes the problem
// Module resolution
"baseUrl": ".",
"esModuleInterop": true,
"moduleResolution": "node",
"module": "esnext",
"paths": {
"@/*": ["resources/js/*"]
},
},
"include": [
"resources/js/**/*.ts",
"resources/js/**/*.tsx",
"resources/js/**/*.vue"
],
"exclude": [
"node_modules"
],
}
Before upgrading to vue 3.2.16 and ts-loader 9.2 I was able to build my app without problems using this tsconfig
After upgrading I can suppress the errors by setting the noUnusedParameters
option to false
but I don't feel that this should be the solution
What is expected?
To build the app without errors
What is actually happening?
app is build with TS lint errors
I also don't know how to reproduce this.
This issue is not actionable without a runnable reproduction. Please provide one or we will have to close the issue.
Mentioning how you upgraded ts-loder to v9, which requires webpack 5, while ts-loader works with webpack 4, I'd suspect you simply have incompatible dependencies here.
My appologies for omitting the reproduction link. I have created an error reproduction repo and updated my initial post.
You may run npm run dev
to see the errors
Please let me know if I can help you to track down this issue
I just run that command in your repo and got 0 errors, just:
Laravel Mix v6.0.31
✔ Compiled Successfully in 2871ms
┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬─────────┐
│ File │ Size │
├─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼─────────┤
│ /js/app.js │ 495 KiB │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴─────────┘
webpack compiled successfully
ah, Interesting.
- The error happens when I run
npm run dev
, - but doesn't happen when I run
yarn dev
, even though that runs the same script. - but when I directly run
yarn mix
(whichyarn dev
runs as well), the errors show up and the build fails.
This is super weird, but I'd guess and say it's somehow related to mix
or the general project setup / deps
@LinusBorg oh, I haven't noticed this strange behavior... Since the problem emerged when I upgraded my node modules (including laravel-mix
package) I opened an issue to laravel-mix and I will report back when I have an update.
It seems that this issue is not related to laravel-mix. I copy from https://github.com/laravel-mix/laravel-mix/issues/3110#issuecomment-927440289
This consistently happens regardless of package manager used to install or run the scripts. It also happens when invoking mix directly using
./node_modules/.bin/mix
. There was one case I saw where it did not happen. I cannot reliably reproduce the situation however which leads me to believe it's possibly a race condition in ts-loader causing it to not report errors in some instances.In any case this has nothing to do with Mix.
The errors happen because of two things:
You have your project configured to error on unused function parameters: https://github.com/iraklisg/vue-typescript/blob/4496628ba4aeb44d42b720c5c0a9deddde232cab/tsconfig.json#L18
Vue SFCs in certain formats result in compiled code with unused arguments intended to be stripped by a production build process: https://sfc.vuejs.org/#eyJBcHAudnVlIjoiPHRlbXBsYXRlPlxuICA8aDE+dGVzdDwvaDE+XG48L3RlbXBsYXRlPlxuPHNjcmlwdD5cbi8vIHN0dWZmXG48L3NjcmlwdD5cbiIsImltcG9ydC1tYXAuanNvbiI6IntcbiAgXCJpbXBvcnRzXCI6IHtcbiAgICBcInZ1ZVwiOiBcImh0dHBzOi8vc2ZjLnZ1ZWpzLm9yZy92dWUucnVudGltZS5lc20tYnJvd3Nlci5qc1wiXG4gIH1cbn0ifQ==
In this case the inclusion of a non-empty
<script>
tag results in the unused parameters being added to the render function while a<script setup>
block does not appear to produce the same results.
For the time being I have disabled the noUnusedParameters
in the tsconfig
in order to be able to run the build. What puzzles me, though, is that before upgrading I could run the build using the same configuration without problems.
Could you please suggest in which direction should I look for the solution because I feel a little bit lost here...
Ah, so it is a problem with Vue's codegen in the sense that it generates unused parameters sometimes - which previously wasn't an issue as the generated render function wasn't actually typechecked, but vue-tsc now does that.
so there's little for you to do, we'll have to research if/how we can improve this.
Also ran into this. Also noticed that it's not entirely deterministic. Removing the output directory and doing a fresh build seems to reliably trigger it for me.
A simple fix might be to unconditionally prefix these parameters with an underscore in the generated code: _$props
, _$setup
, _$options
(and also _$data
and maybe others). This trick seems to be widely applied in the generated code already.