vue-loader: Scoped style leads to error: TS7006: Parameter 'n' implicitly has an 'any' type

“vue-loader”: “16.5” works for me. “vue-loader”: “16.6” failes:

[tsl] ERROR in /src/views/About.vue.ts(3,22)
TS7006: Parameter 'n' implicitly has an 'any' type.

I have the same problem it occurs only if my components have the “scoped” attribute. TS7006: Parameter 'n' implicitly has an 'any' type.

I’m still having this issue on version 17.1.1. Can someone please take a look at this? 🙏 @yyx990803 @sodatea

Removing strict: true from tsconfig.json is a temporary bad workaround, perhaps it would work to allow usage of any instead. I however hope to see this resolved soon.

I solved it this way instead of removing scoped.

tsconfig.json:

{
  "compilerOptions": {
    "noImplicitAny": false,
    ...
  }
}

Also very interested to see the resolution to this issue.

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);

loader: 'ts-loader',
options: {
    ignoreDiagnostics: isWebpackServing ? [] : [7006]
}

This is far from ideal, but I catch most this kind of error during development, mostly in intelliSense.

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 this Parameter '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 🙏🏻

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…

Any news about this issue ? I’m not using script setup just because of that …

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:

{
  test: /\.ts$/,
  exclude: /node_modules/,
  use: {
    loader: "ts-loader",
    options: {
      appendTsSuffixTo: [/\.vue$/],
      compilerOptions: {
        noImplicitAny: false, // Necessary until the following issue is fixed: https://github.com/vuejs/vue-loader/issues/1915
      },
    },
  },
},

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?

I hit this error as well. I’m using v17 with Symfony Webpack Encore. As a workaround, removing scoped from the <style> tags fixed it for me, but I would like to add them back once this is fixed.

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.