Skip to content

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

Open
@shameleo

Description

@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

Activity

chriamue

chriamue commented on Jan 1, 2022

@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

lexeek commented on Jan 27, 2022

@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

stigmh commented on Mar 25, 2022

@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

henrikra commented on Jul 5, 2022

@henrikra

Removing strict is very bad for the codebase.

Have you guys heard any news on this?

CornerSyrup

CornerSyrup commented on Jul 27, 2022

@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

countMort commented on Aug 29, 2022

@countMort

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

yuiidev

yuiidev commented on Sep 20, 2022

@yuiidev

Issue still exists.

entioentio

entioentio commented on Sep 22, 2022

@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

chriskulwik commented on Sep 22, 2022

@chriskulwik

@entioentio where is this variable isWebpackServing defined?

entioentio

entioentio commented on Sep 22, 2022

@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

muster-mark commented on Sep 27, 2022

@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

pkly commented on Oct 25, 2022

@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

sprout2000 commented on Nov 29, 2022

@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',
      ],
    },
  },

8 remaining items

d9r-dev

d9r-dev commented on Oct 23, 2023

@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

adpeyre commented on Jan 1, 2024

@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

brentswisher commented on Jan 11, 2024

@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

Threebow commented on Feb 2, 2024

@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

tehreet commented on Feb 2, 2024

@tehreet

Also very interested to see the resolution to this issue.

Threebow

Threebow commented on Feb 3, 2024

@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

gde-pass commented on Feb 21, 2024

@gde-pass

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

dvogiatzi

dvogiatzi commented on May 23, 2024

@dvogiatzi

@Threebow Thank you very much for the elaborate answer!

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

varun-maersk

varun-maersk commented on May 24, 2024

@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

Threebow commented on May 28, 2024

@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

bspyropoulos commented on Jun 4, 2024

@bspyropoulos

@Threebow seems to be merged!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @nspyke@yuiidev@lexeek@dmfilipenko@stigmh

        Issue actions

          Scoped style leads to error: TS7006: Parameter 'n' implicitly has an 'any' type · Issue #1915 · vuejs/vue-loader