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

[shameleo]

Version

16.8.3, 17.0.0, maybe older

Reproduction link

github.com

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

[chriamue]

"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.

[lexeek]

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

[stigmh]

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.

[henrikra]

Removing strict is very bad for the codebase.

Have you guys heard any news on this?

[CornerSyrup]

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]

Same problem here. I also get some other build time ts errors, resolving by changing strict to false.

[yuiidev]

Issue still exists.

[entioentio]

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.

[chriskulwik]

@entioentio where is this variable isWebpackServing defined?

[entioentio]

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]

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]

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]

I could find a work-around that uses Babel, but maybe not the essential solution.

https://www.npmjs.com/package/babel-preset-typescript-vue3

npm i -D @babel/core @babel/preset-env @babel/preset-typescript babel-loader babel-preset-typescript-vue3

and webpack.config.ts:

  {
    test: /\.ts$/,
    exclude: /node_modules/,
    loader: 'babel-loader',
    options: {
      presets: [
        '@babel/preset-env',
        'babel-preset-typescript-vue3',
        '@babel/preset-typescript',
      ],
    },
  },

[rob-barber]

This was happening to me. For me it wasn't due to the scoped style but rather from using typescript for my script. I removed the lang="ts" from my script tag of my Vue component and it went away.

Edit: Spoke too soon. The above initially worked for me until I added a mixin to the scoped CSS. Now the original issue is back.

[nspyke]

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.

[sakotsu]

I solved it this way instead of removing scoped.

tsconfig.json:

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

[BR0kEN-]

Greet me in the club.

The problem mysteriously does not appear in the watch mode (I'm using the Laravel Mix) so I came up with the idea to set the noImplicitAny TS compiler option to false for the non-watching Webpack modes.

Replace Mix.isWatching() with your logic for determining the watch mode.

// @todo Delete once https://github.com/vuejs/vue-loader/issues/1915 is resolved.
// @todo Don't forget to remove the issue mention from the README.md.
const tsOptions = Mix.isWatching()
  ? undefined
  : {
    compilerOptions: {
      noImplicitAny: false,
    },
  };

mix
  .ts('js/app.ts', 'js', tsOptions)
  .vue();

The Webpack rule would have looked this way:

{
  test: /\.tsx?$/,
  loader: 'ts-loader',
  options: {
    appendTsSuffixTo: [/\.vue$/],
    ...(Mix.isWatching() ? {} : { compilerOptions: { noImplicitAny: false } })
  },
}

[chriskulwik]

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

[dmfilipenko]

Same here. All of these symptoms.
I'm trying to write the SFC component

<script lang="ts" setup>
//something
</script>
<template>
<div>
</div>
</template>
<style scoped>
</style>

Without scoped attribute everything works fine. Also without the setup attribute everything is also works fine.

[d9r-dev]

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]

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 :

• TS2322: Type '{ to: { name: string; }; label: string; }' is not assignable to type 'string | number | symbol | undefined'

This error is not detected in dev mode.

[brentswisher]

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?

[Threebow]

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 🙏🏻

[tehreet]

Also very interested to see the resolution to this issue.

[Threebow]

In essence, I was having significant dificulty using this older version while trying to set up my types how I wanted to.

To elaborate on this and show an example of the error I get instead of this one when downgrading to 16.5:

Module Error (from ./node_modules/.pnpm/vue-loader@16.5.0_webpack@5.89.0/node_modules/vue-loader/dist/templateLoader.js):
[@vue/compiler-sfc] No fs option provided to `compileScript` in non-Node environment. File system access is required for resolving imported types.

.\<redacted>\src\modules\Error.vue
5  |    import type { ErrorDTO } from "@/modules/Error.dto"
6  |  
7  |    defineProps<ErrorDTO>()
   |               ^^^^^^^^
8  |  </script>
9  |  

@/modules/Error.dto is a file Error.dto.ts that contains only the following few lines:

export type ErrorDTO = {
	status: number
	eventId?: string
	extra?: string
}

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 an index.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]

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

[dvogiatzi]

@Threebow Thank you very much for the elaborate answer!

The issue still persists in May 2024. Any updates on this?

[varun-maersk]

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...

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]

The issue still persists in May 2024. Any updates on this?

@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.

How did you figure this out first? What made you think about scoped??

@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]

@Threebow seems to be merged!