Open
Description
Version
16.8.3, 17.0.0, maybe older
Reproduction link
Steps to reproduce
npm install
npm run dev
What is expected?
No errors
What is actually happening?
Error: TS7006: Parameter 'n' implicitly has an 'any' type
To get this error style must be scoped and template must access some component data
Activity
chriamue commentedon Jan 1, 2022
"vue-loader": "16.5" works for me. "vue-loader": "16.6" failes:
lexeek commentedon Jan 27, 2022
I have the same problem it occurs only if my components have the "scoped" attribute.
TS7006: Parameter 'n' implicitly has an 'any' type.
stigmh commentedon Mar 25, 2022
Removing
strict: true
fromtsconfig.json
is a temporary bad workaround, perhaps it would work to allow usage ofany
instead. I however hope to see this resolved soon.henrikra commentedon Jul 5, 2022
Removing strict is very bad for the codebase.
Have you guys heard any news on this?
CornerSyrup commentedon Jul 27, 2022
I got 4 components having the same problem.
Those failed to build with Webpack, but succeed in watch mode.
It first fail in watch mode, but I got succeed after removing
scoped
in one of them.The best part is, it still work even I put it back...
countMort commentedon Aug 29, 2022
Same problem here. I also get some other build time ts errors, resolving by changing strict to false.
revert vue-loader version - see vuejs/vue-loader#1915
yuiidev commentedon Sep 20, 2022
Issue still exists.
entioentio commentedon Sep 22, 2022
I found this thread finally! Was trying to wrap my head around this issue in the span of the last couple of weeks.
My (somewhat silly) workaround is to disable the check when building (it doesn't fail when serving);
This is far from ideal, but I catch most this kind of error during development, mostly in intelliSense.
chriskulwik commentedon Sep 22, 2022
@entioentio where is this variable
isWebpackServing
defined?entioentio commentedon Sep 22, 2022
Sorry, true that. That's my local variable in webpack.l config
const isWebpackServing = !!~process.argv.indexOf('serve');
but you can check either mode in which webpack is working or environment.muster-mark commentedon Sep 27, 2022
I get this errror even when the template is not accessing component data. It worked fine when the template was
<div></div>
, but I got the error with a child element - i.e. when changing it to<div><span></span></div>
.Using v17.
pkly commentedon Oct 25, 2022
I thought I was going insane since I couldn't see anything.
Very much an issue in 17, annoying for usage with Webpack Encore since it's <15 and >=17.
sprout2000 commentedon Nov 29, 2022
I could find a work-around that uses Babel, but maybe not the essential solution.
https://www.npmjs.com/package/babel-preset-typescript-vue3
and
webpack.config.ts
:8 remaining items
d9r-dev commentedon Oct 23, 2023
I stumbled upon this issue. The problem still exists. Only solution I could find is to remove the scoped attribute from the style tag.
adpeyre commentedon Jan 1, 2024
Same issue for me.
I also have more errors in prod mode compared to dev mode.
Example with a bad type for v-key in a vue component :
This error is not detected in dev mode.
brentswisher commentedon Jan 11, 2024
Just ran into this issue in the latest version too, turns out our organization has run into this pretty frequently lately 😞
I opted to add a targeted setting to set
noImplicitAny
to false only at build time as a workaround, so at least it flags in the IDE, but still doesn't feel great:What was really weird was if I ran it using
webpack serve
it would error, but if I re-saved the file it was erroring on without changing anything, the error went away and the project compiled successfully. However,webpack build
consistently failed every time.Feels like maybe some kind of a race condition?
Threebow commentedon Feb 2, 2024
I am having the same issue. Initially, I downgraded to
16.5
as suggested by @chriamue, and that worked for me. However, in newer vue-loader versions, there have been numerous fixes made to remedy issues that occur as a result of using imported types as props (see vuejs/core#8482). In essence, I was having significant dificulty using this older version while trying to set up my types how I wanted to. Updating to the newest version, I now get only thisParameter 'n' implicitly has an 'any' type.
error.It seems that it may be an issue in Vue's SFC compiler: @xesxen made a pull request that seems like it would fix the cause of this here, I am not 100% sure without some input from them. Regardless, it would be amazing to see this issue addressed, especially since it is causing big issues for many people as evident in this thread, and seeing as people have made active attempts to fix it (i.e. the aforementioned PR) that have seem to been lost in the sea of issues and PRs.
Would it be possible to please have someone take a look at this after so long? @yyx990803 @sodatea 🙏🏻
tehreet commentedon Feb 2, 2024
Also very interested to see the resolution to this issue.
Threebow commentedon Feb 3, 2024
To elaborate on this and show an example of the error I get instead of this one when downgrading to
16.5
:@/modules/Error.dto
is a fileError.dto.ts
that contains only the following few lines:Initially, I tried to resolve this by making a fork of 16.5 and passing the
fs
option it requested as vue-loader doesn't export that option (see #2041, open for 9 months without a response).I ended up getting it to work on occasion, but I was having a lot of really weird issues with imported types, and I could never get it working properly. Eventually I decided to give up on the fork idea and just tried to get it working with the newest version, but I experienced an issue with using intersections of imported types as props (see vuejs/core#8482).
It's incredibly frustrating that I've spent weeks on this and nothing works as expected. It always boils down to some arbitrary error that appears to come from
vue-loader
's generated*.vue.ts
facade module. I would use Vite, but Vite does not natively support my use-case of backend bundling for SSR (manual server-side rendering with Koa, without anindex.html
file), so I cannot use it.A warning for anyone coming here from Google in 2024:
If you are looking to use modern TypeScript within your Vue components or frontend code in general, and want to use vue-loader to integrate it within your webpack build, I strongly recommend you don't do so, either until these issues are fixed, or until
vue-loader
is finally deprecated and someone more tied into Webpack's ecosystem takes it upon themselves to maintain a better solution.In my personal experience using many non-Vite bundlers, Vue+TS does not work as you'd expect in a lot of circumstances, unless you are using Vite alongside it. I am considering migrating away from Vue in my project for these reasons, as it seems the advent of Vite has led legacy modules that people still rely on (like
vue-loader
) to shy away from being supported.Really hoping this changes, but unfortunately it seems that this is the way things are going for now.
gde-pass commentedon Feb 21, 2024
Any news about this issue ? I'm not using script setup just because of that ...
dvogiatzi commentedon May 23, 2024
@Threebow Thank you very much for the elaborate answer!
The issue still persists in May 2024. Any updates on this?
varun-maersk commentedon May 24, 2024
Removing scoped from style in Vue3 <script setup lang="ts"> fixed the issue. But I don’t understand the root cause though 🙂↔️ .
How did you figure this out first? What made you think about scoped??
Please share your thoughts.
Threebow commentedon May 28, 2024
@gde-pass @dvogiatzi I am actively watching this, and it doesn't seem so. My use case has extended to Zod type inference, and it has led me to hit further blockers, so I am very interested in a solution to this. The PR that I think might fix this issue has had no activity for three months either, so I will probably look into creating a PR myself if I find the time. The only problem is I wouldn't want my PR to end up in the graveyard.
@varun-maersk On the surface, it is indeed absolutely bizarre that enforcing a scoped style will trigger arbitrary type errors in the TS section of the code. It would seem that they are different cogs in the system, and as such, shouldn't affect each other. However, the way it really works (to my understanding, at least) is that
vue-loader
's code generation (i.e. the generated facade file,X.vue.ts
) implements various logical switches to build the generated code, based on what template sections you have provided (i.e.script
,style
,template
) and their properties (i.e.lang
,scoped
,generic
).So, what is happening here (again, to the best of my understanding, I could be completely wrong here), is that the presence of a scoped style is outputting some non-strict-mode-compliant TypeScript code, somewhere within the generated
X.vue.ts
facade file, and that is causing the entire file to fail compilation. So, it doesn't matter where the error is or what part of the overall SFC system it affects, instead, the mere presence of an error in the generated code will break the entire import.P.S.
I've also experienced different behavior depending on whether code is added while Webpack is "warmed up" in watch mode, v.s. freshly booted in watch mode. So, the code will error when you add it to project that's actively being watched, however, if you do not change the code whatsoever and restart the watch process, it will then work and the error will disappear.
bspyropoulos commentedon Jun 4, 2024
@Threebow seems to be merged!