Vue 2.7.14 ... migration from Webpack to Vitejs, extend Vue

[SaschaAusUlm]

Discussed in https://github.com/vitejs/vite-plugin-vue2/discussions/81

^{Originally posted by SaschaAusUlm March 22, 2023} Hi!

We're trying to convert our application (Vue.js 2.7.14) to Vitejs as preparation for a Vue 3 migration later this summer. So I migrated and "vite build" works fine. But when I run the application, I encounter the error that our logging mechanism no longer works.

We do a:

` declare module 'vue/types/vue' { export interface Vue { $log: CubeLogger; } }

declare module 'vue/types/options' { export interface ComponentOptions { log?: CubeLogger; } } `

with CubeLogger being our specialized logging component. In our main.ts we're then assigning an instance of our logger, so that "$log" exists on "this". Works with Webpack.

But using Vitejs, "this.$log" is undefined and I am not getting far.

Asked on the Vitejs forum here: https://github.com/vitejs/vite/discussions/12508

They said probably an issue with vite-plugin-vue2. Is that scenario supported with the vite-plugin-vue2?

If so, then I will submit a test case, no big deal. Just wanted to ask before. Thanks.

[ragnese]

I also have recently migrated a project from vue-cli to vite, in hopes of migrating to Vue 3 soon. And I ran into similar issues. Are your declare module statements located in the "project" as defined by your tsconfig.json (include or files)?

One thing that was causing a lot of issues for our project was that TypeScript stopped seeing the declare module statements from third party libraries in node_modules. I realized that the reason for this was because I had changed my tsconfig.json moduleResolution to "bundler" from "node", and with that moduleResolution strategy it won't detect the delcare module statements if they're inside a file that has imports or exports at the top level. So, a bunch of older libraries were written in a way that doesn't work with this strategy. The "fix" for now seems to be to change moduleResolution back to "node" ("node16"/"nodenext" also don't work for me). Based on my naive understanding of how "node" and "bundler" work, I think this is safe, since it seems like "bundler" is mostly just more flexible with its imports.