[Bug Report] "$attrs is readonly" and "$listeners is readonly" console messages.

[appurist]

Versions and Environment

Vuetify: 1.1.0-alpha.4
Vue: 2.5.16
Browsers: Chrome 66.0.3359.139
OS: Linux x86_64

Steps to reproduce

• clone the repo at https://github.com/appurist/electrify
• run yarn dev

Expected Behavior

Normal console messages (quieter). This was the case in 1.0.

Actual Behavior

This pair of messages appears for every button in the toolbar. There are two buttons in the repo example, so there are four messages total (first 2 shown below, repeats not shown).

./node_modules/vue/dist/vue.runtime.common.js:589 [Vue warn]: $attrs is readonly.

found in

---> <VBtn>
       <VToolbar>
         <VApp>
           <Electify> at src/renderer/App.vue
             <Root>
warn @ ./node_modules/vue/dist/vue.runtime.common.js:589
./node_modules/vue/dist/vue.runtime.common.js:589 [Vue warn]: $listeners is readonly.

found in

---> <VBtn>
       <VToolbar>
         <VApp>
           <Electify> at src/renderer/App.vue
             <Root>
warn @ ./node_modules/vue/dist/vue.runtime.common.js:589

Reproduction Link

https://github.com/appurist/electrify

Other comments

1. Replace 1.1.alpha.4 with 1.0 and the messages disappear.
2. Removing the buttons resolves the messages.
3. Removing the footer entirely resolves the messages.
4. Removing app from the footer resolves the messages.
5. Removing app from the header does NOT resolve the messages.
6. Replacing the v-button/v-icon combinations with simple v-icon resolves the messages.

Note: If the dev tools are not visible for the console when running the app, Ctrl-Shift-I shows them (also menu). I was unable to reproduce this with a web build of the app, thus unable to reproduce with a simpler codepen either; there may be some kind of conflict between Vuetify's use of an app mix-in and Electron.

[appurist]

I believe the problem may lie in src/mixins/applicationable.js due to the watch triggering an unbind/bind sequence after Vue has completed initialization. (Is this used anywhere other than Jest testing?)

[appurist]

Note that the warnings only come out (from Vue) in src/core/instance/lifecycle.js if isUpdatingChildComponent (which starts as true) has already been set to false. This is expected to be true once and then report this error if modifications are attempted after it is cleared.

There are several references to this error being triggered if Vue is included more than once (e.g. more than one version) but I don't think that's the case here. More detail here.

[appurist]

Oh I just found this: vuejs/vue-test-utils#532
The "two instances of Vue" problem might be esm vs commonjs.

[KaelWD]

two instances of Vue

That'll probably be because we have to import vue ourselves now for TS to work. Particularly if it only happens with VBtn. I tried fixing this with 4890c83 but I think it'll need to be factory functions instead unfortunately.

[KaelWD]

This should change it for us too: https://github.com/appurist/electrify/blob/master/.electron-vue/webpack.renderer.config.js#L125

Were you using yarn link?

[appurist]

I started by making the same change in my webpack file and it did not help, it seems like there's still two different paths to Vue, even if they are all esm, which may mean two instances. With webpack, if one path is absolute and one is relative, perhaps it treats those as different? Or one is being webpacked and one not...

I had used yarn link earlier, but once I completed my commits/PRs, while trying to track this down, I had reinstalled vuetify@next and nuked the whole node_modules tree and reinstalled. Also, my coworker has the same trouble and doesn't use link. It doesn't seem to affect our web build, maybe it's defaulting to production there, but it does affect both our 'dev' and 'build' Electron builds.

But it's not Electron-specific, the vue-test-utils issue mentioned above includes a codesandbox repro which isn't electron. They made a change in a beta update and when they attempt to use it with Vuetify, they have the same problem. (That looks like maybe 1.0 of our code here, but their explanation for the trigger may provide a clue, changing their waters to sync triggering an extra rerender.

To be honest, this feels like a bug in the check in Vue to me, but I don't really understand the problem yet so the jury is out on that.

Hmmm. Is the Vuetify load of Vue available from the object, e.g. as Vuetify.$vue or something like that? If so, maybe instead of importing it we just assign it like Vue = Vuetify.$vue and use that one.

[KaelWD]

Yeah I'm not sure either, but as it's happening outside of tests and works fine with vuetify 1.0, I don't really know what else it could be. Vuetify's vue import is not made available anywhere, but WebpackBundleAnalyzer will show if there's different versions loaded.

I had to do this to the docs repo to prevent it from loading vue from the symlinked node_modules: vuetifyjs/legacy-docs@5fa3c69

[johnleider]

This will occur when using a locally linked Vuetify package and not aliasing vue to the esm file.

[vegerot]

How do I test a locally linked Vuetify package?

Not quite sure where I alias the esm file. Do I do the alias in my vue.config.js?

[vegerot]

I know this is probably a silly question, but what I want to do is "transparently" replace the npm installd Vuetify with the Vuetify I've built locally. I don't want to change my project at all for this to work

[bdeo]

This still occurs even even with aliasing 'vue$': 'vue/dist/vue.esm.js', in webpack config for jest/vue-test-utils tests for me.

[johnleider]

In regards to vue-test-utils, this was a bug introduced in beta updates, vuejs/vue-test-utils#532

[appurist]

In my repo above, I'm not doing any tests, or using vue-test-utils at all. I've also tried forcing the vue$ alias with both relative and path.resolve naming to no effect. I've also just confirmed it reproduces with the beta.0 release, however, I see now that the two versions of Vue are loaded, mostly vue.esm.js but also vue.common.js for the top three stack frames:

As far as I can tell, that's all Vue code, just two copies and in the instance that complains, the isUpdatingChildComponent was initialized to false and updateChildComponent is never called (in that instance of Vue) so it has never been set to true.

The Vue check is to confirm that the code is in updateChildComponent (which it is, 4th stack frame in the traceback) but it is in the other instance so the boolean is still false in the runtime-only instance.

[KaelWD]

tl;dr: Externalising vue but not vuetify causes duplicate modules. Add vuetify in here too to fix it: https://github.com/appurist/electrify/blob/master/.electron-vue/webpack.renderer.config.js#L21

What's happening is you have a copy of vue that's been run through webpack (the one in renderer.js, image 1) and the original straight from node_modules (image 2). Your application uses the webpacked one, and vuetify imports the original directly because webpack doesn't touch it. This wasn't a problem in 1.0 because our components were just bare objects, but now with typescript we have to export vue instances instead.

[appurist]

Aha, I finally understand how the second copy is being loaded, which is which, etc. Thanks so much @KaelWD !

And I can confirm that if I include both vue and vuetify in that whiteListedModules list (i.e. treat them both the same way in the externals section of the config), that the problem goes away for both the 'electrify' sample repo above, as well as our internal project.

Case closed, we don't even need a change to Vuetify for this, we can take care of it in our webpack configs.

[appurist]

I think this issue can be considered resolved, especially with Vue issue #8278 tracking the better longer-term solution.

The actual fix for this is to ensure both Vue and Vuetify are treated the same way in the webpack externals, e.g. putting both (or neither?) in the let whiteListedModules = ['vue', 'vuetify'] line in these vuetify webpack builds.

[Phancie]

The vuetify webpack being referred to here is the webpack.renderer.config.js which can be found in the .electron-vue folder.
Took me 3days to figure it out. Hope it makes someone else's life more easier

[mirikerstein]

Hi appurist, if you're still around, can you expand on the solution a bit? I'm stuck on this as well... thanks.

[VIXI0]

STOP!! HERE IS THE ANSWER let whiteListedModules = ['vue', 'vuetify'] IS LOCATED IN webpack.renderer.config.js

THANKS TO @appurist

[darylteo]

@KaelWD @johnleider

Posting here as I can't find the time to create a reproduction at work for now.

Upgrading to v1.1.1 - this issue seems to occurring for my project because I was vendoring vuetify using Webpack 4 DllPlugin. The problem seems to go away if I've taken vuetify out of the vendoring. Whether "vue" is in the vendoring or not don't seem to make a difference.

If you think this is a legit issue you'd like to look at, please let me know if I should open a new ticket or if you'd just like to reopen. Thank you.

Dary

[andreixk]

If you run into this problem via a Rails web app, here is a skeleton app on how to fix it

https://github.com/lukebyrne/rails-vuetify-test

Just follow the git commits to see the changes made to get it resolved.

Many thanks to @KaelWD

the link is dead @lukebyrne

[emancypage]

That is, typically in the .electron-vue/webpack.renderer.config.js file, or where ever your webpack config file is. Find the whiteListedModules assignment and make sure it includes both 'vue' and 'vuetify'.

But i'm not in a electron app, how to add whiteListedModules in vueconfig/VueCLI3 ?
I tried insert in chainWebpack, but it doesn't work

@AlexandroWillianHervis - did you solved this problem? I have the same problem now

[yangfei2013]

solved my problem,thanks.@emancypage

[oHervis]

@emancypage. I fixed by removing the vuetify-loader of my package.json: Try it.

[VRuzhentsov]

@emancypage. I fixed by removing the vuetify-loader of my package.json: Try it.

Can't remove that loader, because of peerDependency of @nuxtjs/vuetify

[johnleider]

There will be no absolute fix for this in the v2 major. This will naturally resolve in v3 with the new composition api.

If you have any additional questions, please reach out to us in our Discord community.

[Chris-McQueen-Development]

@emancypage. I fixed by removing the vuetify-loader of my package.json: Try it.

This didn't work for me. Anyone else achieved a workaround?

[dltmd6262]

Is this possibly going anywhere..? I've been having this problem after adding firebase cloud functions folder to my project...

[jacekkarczmarczyk]

@dltmd6262 #4068 (comment)

[KaelWD]

There seems to be some confusion around this as it can be caused by a few unrelated things:

Unit testing

We use Vue.extend in our components, so the vuetify plugin must be installed globally to work properly.

Incorrect:

import Vuetify from 'vuetify'
import { mount, createLocalVue } from '@vue/test-utils'
import component from './my-component.vue'

const localVue = createLocalVue()

localVue.use(Vuetify)

describe('module', () => {
  let vuetify
  beforeEach(() => {
    vuetify = new Vuetify()
  })

  it('should do something', () => {
    const wrapper = mount(component, {
      localVue,
      vuetify
    })
  })
})

Correct:

import Vue from 'vue'
import Vuetify from 'vuetify'
import { mount, createLocalVue } from '@vue/test-utils'
import component from './my-component.vue'

Vue.use(Vuetify)

const localVue = createLocalVue()

describe('module', () => {
  let vuetify
  beforeEach(() => {
    vuetify = new Vuetify()
  })

  it('should do something', () => {
    const wrapper = mount(component, {
      localVue,
      vuetify
    })
  })
})

Non-default vue import

Incorrect:

// main.js
import Vue from 'vue/dist/vue.runtime.esm.js'

Correct:

// main.js
import Vue from 'vue'

// webpack.config.js
module.exports = {
  //...
  resolve: {
    alias: {
      'vue$': 'vue/dist/vue.runtime.esm.js'
    }
  }
}

Monorepo/symlinks

If you have a directory structure like this:

project/
├── app/
│   └── node_modules/
│       └── vue/
└── library/
    └── node_modules/
        └── vue/

or are developing a library and testing it with yarn link

import Vue from 'vue' will resolve project/app/node_modules/vue in the app and project/library/node_modules/vue in the library, resulting in two copies of vue being loaded. We need to configure webpack to only load one.
The first step is making sure the library doesn't include vue or vuetify when it's built:

// library/webpack.config.js
module.exports = {
  //...
  externals: {
    vue: {
      commonjs: 'vue',
      commonjs2: 'vue',
      amd: 'vue',
      root: 'Vue'
    },
    vuetify: {
      commonjs: 'vuetify',
      commonjs2: 'vuetify',
      amd: 'vuetify',
      root: 'Vuetify'
    }
  }
}

Then we tell the app to only load its copy:

// app/webpack.config.js
const path = require('path')
module.exports = {
  //...
  resolve: {
    symlinks: false,
    alias: {
      'vue$': path.resolve(__dirname, 'node_modules/vue/dist/vue.runtime.esm.js'),
      '^vuetify': path.resolve(__dirname, 'node_modules/vuetify')
    }
  }
}

[vegerot]

@flyingL123 thanks!

[plweil]

Worked for me, too. Thank you!

[sidouglas]

Worked for me too.

[glennpjones]

Thank you so much, so glad this worked. Amazing how impossible it seems to debug this issue

[jansen-imagem]

I too was struggling with this bug. I'm experimenting with nuxt-extend. When having a base and an app where you would like to use treeshake, youll only need to alias vue and vuetify in the app to prevent ending up with two vuetify instances like I did. Whenever someone comes around here with issues like this scenario, give it a try to leave the external out

[andreixk]

createLocalVue is designed specifically to prevent polluting the global Vue instance. Especially if not all the tests require some plugins or test behaviour that assumes the plugin to not exist.

[KaelWD]

Too bad, it doesn't work with Vue.extend()

[dennyf]

For anyone experiencing this problem with Rails and Webpacker if you are importing Vue with the compiler:

import Vue from 'vue/dist/vue.esm'

to resolve this issue add the following line to the config/webpack/environment.js file:

environment.config.resolve.alias = { 'vue$': 'vue/dist/vue.esm.js' };

just before this line:

module.exports = environment

[jefraroce]

Really thanks :)

[ferndot]

@dennyf you're a lifesaver, thanks!

[Saveriu]

Hi! I'm working on a Vue Microfrontend POC with Vuetify and SystemJS: https://github.com/Saveriu/vue-microfrontends
I have a lot of errors when I load a Vuetify (/app2) app into another (/main).
I think it's caused by a confusion between webpack modules at build time and systemjs at runtime.
If you guys have the time to check on that project it will be great! Thanks a lot!

[souljorje]

Vite/Rollup solution

I have some kinda microfrontend case: private vue app uses open source app as dependency (locally, i.e. "package": "file:...") where vuetify is imported. Had two vuetifys & vues in my bundle & error from issue title before this fix.

// vite.config.js

export default () => defineConfig({
 resolve: {
    alias: {
      vue: path.resolve(__dirname, './node_modules/vue/dist/vue.runtime.esm.js'),
    },
    dedupe: ['vuetify', 'vue'],
  },
});

For rollup pass dedupe to @rollup/plugin-node-resolve and alias to @rollup/plugin-alias entries.

[lukicenturi]

Hi @souljorje, I'm still facing the problem. May I know what version of Vite, Vue, and Vuetify you used? Maybe I can also see your full vite.config.js?

[souljorje]

@lukicenturi 👋, sure!

"vue": "2.6.14",
"vuetify": "2.6.3",
"vite": "2.9.8"

// vite.config.mjs

import { createRequire } from 'module'; // 🚲
import path from 'path';
import url from 'url';

import ViteComponents from 'unplugin-vue-components/vite';
import { defineConfig } from 'vite';

import { aliases } from './build/utils.mjs';

const __dirname = path.dirname(url.fileURLToPath(import.meta.url));

const require = createRequire(import.meta.url);

const pkg = require('./package.json');

const { dependencies } = pkg;
const d3Packages = Object.keys(dependencies).filter((v) => v.startsWith('d3'));

// vuetify components that I've extended locally, must be ignored by unplugin-vue-components/vite
const vuetifyExtensions = new Set([
    'VListExtended',
    'VListItemGroupExtended',
    'VTooltipExtended',
    'VMenuExtended',
]);

export default (ctx) => {
    const optimizeDepsInclude = [
        '@vue/composition-api',
        '@vueuse/core',
        'bignumber.js',
        'chart.js',
        'lru-cache',
        'marked',
        'prismjs',
        'topojson-client',
        'vue-json-pretty',
    ];
    const optimizeDepsExclude = [
        ...d3Packages,
        'swrv',
        'vue',
        'vue-router',
        'vue-virtual-scroll-list',
        'vuetify',
        'vuex',
        'vue-gtag',
        '@tzkt/ui',
        '@tzkt',
    ];
    return defineConfig({
        build: {
            target: 'esnext',
            commonjsOptions: {
                transformMixedEsModules: true,
            },
            rollupOptions: {
                output: {
                    manualChunks: (id) => {
                        if (id.includes('node_modules')) {
                            if (id.includes('vue.runtime.esm')) return 'vue';
                            if (id.includes('d3-')) return 'd3';
                            if (id.includes('bignumber.js')) return 'bignumber';
                            if (id.includes('buffer')) return 'buffer';
                            if (id.includes('vuetify/lib')) return 'vuetify';
                        }
                        return undefined;
                    },
                },
            },
        },
        server: {
            open: true,
        },
        plugins: [
            ViteComponents({
                resolvers: [
                // with vue 3.0 use https://www.npmjs.com/package/@vuetify/vite-plugin
                // eslint-disable-next-line consistent-return
                    (name) => {
                        if (name.match(/^V[A-Z]/) && !vuetifyExtensions.has(name)) {
                            return { importName: name, path: 'vuetify/lib' };
                        }
                    },
                ],
            }),
        ],
        resolve: {
            alias: {
                ...aliases,
                vue: path.resolve(__dirname, './node_modules/vue/dist/vue.runtime.esm.js'),
                /**
                 * polyfill stream https://github.com/vitejs/vite/issues/3817#issuecomment-864450199
                 * & fix esm-related issues https://github.com/nodejs/readable-stream/issues/439#issuecomment-940643578
                 */
                'readable-stream': 'vite-compatible-readable-stream',
                stream: 'vite-compatible-readable-stream',
            },
            dedupe: [
                ...optimizeDepsInclude,
                ...optimizeDepsExclude,
            ],
        },
        /**
         * Due to mirror replace some stuff is explicitly imported in Vite's opinion, need to relax it by implicit declaration, so it won't make unnecessary rebuilds.
         * If you see `[vite] new dependencies found: ...` in console, add corresponding packages to `exclude` if it's ESM and to `include` if CJS.
         */
        optimizeDeps: {
            include: optimizeDepsInclude,
            exclude: optimizeDepsExclude,
            esbuildOptions: {
                target: 'es2021',
            },
        },
    });
};

[kimbaudi]

instead of vue: path.resolve(__dirname, './node_modules/vue/dist/vue.runtime.esm.js'),, i did vue: 'vue/dist/vue.runtime.esm.js', and it works. no need to resolve path to __dirname.

[jellehak]

instead of vue: path.resolve(__dirname, './node_modules/vue/dist/vue.runtime.esm.js'),, i did vue: 'vue/dist/vue.runtime.esm.js', and it works. no need to resolve path to __dirname.

This solved the problem. 👍
NOTE: our issue occurred when upgrading from vite 3 to vite 4