App-vite v3 with rolldown need additional configuration on __some__ projects/

[FragsterAt]

On some older projects after upgrading to app-vite v3 dev server works fine, but built app fails to run. The error in browser console looked like TypeError: undefined is not a function <anonymous> runtime-dom.esm-bundler.js:112, sometimes it contains different filenames. After some investigation, I found that the reason is circular dependencies in vuejs internal packages, which Rolldown splits into different chunks.

The solution is to configure Rolldown to put everything vuejs related into a single bundle. This can be done with extendViteConf, for example:

      extendViteConf(viteConf) {
        viteConf.build ??= {}
        viteConf.build.rolldownOptions ??= {}
        viteConf.build.rolldownOptions.output ??= {}
        const codeSplitting = {
          groups: [
            {
              name: 'vue',
              test: /[\\/]vue[\\/]/,
              priority: 20,
            },
          ],
        }
        if (Array.isArray(viteConf.build.rolldownOptions.output)) {
          const output = viteConf.build.rolldownOptions.output[0]
          if (output) {
            output.codeSplitting = codeSplitting
          }
        } else {
          viteConf.build.rolldownOptions.output.codeSplitting = codeSplitting
        }
      },

Maybe it should be included in the default Quasar configuration?

[IMONsergey]

I would keep this as a project-level workaround until there is a minimal reproduction showing that Quasar's default chunking is the cause. A global “all Vue code in one chunk” rule changes caching and bundle parallelism for every application, while this failure may depend on the upgraded project's dependency graph.

Two checks are especially useful before proposing a default:

• confirm there is only one Vue runtime in the production graph (for example, inspect the package-manager tree for vue, @vue/runtime-dom, and @vue/runtime-core);
• compare a fresh app-vite v3 project with the upgraded project, then add its dependencies/configuration until the failure appears.

Also note that /[\/]vue[\/]/ does not necessarily cover scoped @vue/* paths. If the intent is to keep the whole runtime together, test a pattern that explicitly covers both vue and @vue under node_modules, and verify the emitted chunks rather than assuming the group matched.

If a clean reproducer still fails only after production chunking, attach the before/after chunk list and the smallest dependency set to a Quasar issue. That gives maintainers enough evidence to decide whether the fix belongs in Quasar, Vue/Rolldown interop, or a dependency's packaging. Until then, documenting extendViteConf as a targeted mitigation is safer than enabling it for all apps. Quasar documents that hook in the build configuration reference.

[FragsterAt]

confirm there is only one Vue runtime in the production graph (for example, inspect the package-manager tree for vue, @vue/runtime-dom, and @vue/runtime-core);

yes, there is only one version of vue and @vue/* packages (3.5.40)

In a fresh project there is no error. Different runtime chunks appeared when I import some Vue-related things in boot files and in other source files, but there is no error. Maybe you can see something in rollup-plugin-visualizer output.

stats.html of broken build
stats.html of fresh project with boot files, directives etc. without error

Maybe error is related to chunk size limit and cannot be reproduced in small projects?

[stefanvanherwijnen]

Maybe error is related to chunk size limit and cannot be reproduced in small projects?

Something like this is probably the case. For me in some projects it works fine, then in other projects I get these same errors.
This is caused by Rolldown by the way, not by Quasar itself: vitejs/vite#22286

[FragsterAt]

This is caused by Rolldown by the way, not by Quasar itself

That's why I haven't opened an issue. Perhaps workaround should be included in the base config generated by Quasar? Or should the potential problem be documented in official docs?

Before the problem appeared, I hadn't added anything to extendViteConf by myself, and the problem appeared with the update to App-vite v3 and Vite 8