Uncaught Reference Error in Vue3 When Using ESM Runtime Bundle (for in HTML templates)

[an0nusr]

🐛 bug report

When running in development, there are no issues, but after running parcel build, the application fails to run with ReferenceErrors.

This seems similar to bug #6711, but only occurs for me when working with runtime templates (when using the vue.runtime.esm-bundler.js file). When working with Vue files/compiled templates, I don't see the problem.

I'm able to work around the issue by adding --no-scope-hoist to the build command.

🎛 Configuration (.babelrc, package.json, cli command)

{
  "name": "storything",
  "version": "1.0.0",
  "license": "MIT",
  "source": "src/index.html",
  "scripts": {
    "start": "parcel",
    "build": "parcel build --public-url ./"
  },
  "browserslist": "> 0.5%, last 2 versions, not dead, not IE 11",
  "devDependencies": {
    "parcel": "^2.4.1",
    "parcel-reporter-static-files-copy": "^1.3.4"
  },
  "alias": {
    "vue": "./node_modules/vue/dist/vue.esm-bundler.js"
  },
  "dependencies": {
    "@yaireo/tagify": "^4.11.0",
    "papaparse": "^5.3.2",
    "vue": "3"
  }
}

🤔 Expected Behavior

Built version should behave like the dev version (no reference errors)

😯 Current Behavior

Page fails to load with the following error:

Uncaught ReferenceError: $107e461a639a0bee$import$4f81359071792c76 is not defined
    at pi (vue.esm-bundler.js:61:47)
    at vi (runtime-core.esm-bundler.js:7628:10)
    at runtime-core.esm-bundler.js:7506:9
    at gi (runtime-core.esm-bundler.js:7425:10)
    at R (runtime-core.esm-bundler.js:5108:40)
    at A (runtime-core.esm-bundler.js:5099:17)
    at _ (runtime-core.esm-bundler.js:4657:34)
    at ee (runtime-core.esm-bundler.js:5817:13)
    at mount (runtime-core.esm-bundler.js:3996:21)
    at Object.t.mount (runtime-dom.esm-bundler.js:1620:12)

🔦 Context

I would like to use vue with in-html templates because I'm building a web app that itself is a template. I'd like it to be easy for people to modify how things look without having to rebuild the javascript components.

With the --no-script-hoist work around, this isn't a major issue, but it isn't well documented/called out.

💻 Code Sample

Full code is available here (though this uses the no-scope-hoist workaround): https://github.com/an0nusr/storything/tree/vue-with-html-template

An alternate version using Vue SFCs instead is here (and doesn't have the issue): https://github.com/an0nusr/storything/tree/vue

🌍 Your Environment

Software	Version(s)
Parcel	2.4.1
Node	12.22.17
npm/Yarn	1.22.5 (yarn)
Operating System	Ubuntu 18.04

[smoli]

Experiencing the same behavior.

@an0nusr thank you so, so much for the workaround!

Parcel 2.2.1
Node 16.3.2
npm 8.1.2
OS Windows 10
vue 3.2.29

[Jengamon]

Ok, so this is a bit confusing, but for any vue bundle with the runtime tag ("vue.runtime.*"), you can't use runtime compilation, as those bundles "only contain the runtime".

See this

Basically, you have to alias "vue" as "vue/dist/vue.esm-bundler.js" if you want runtime compilation of templates.

[Jengamon]

Hmm, production still errors out with the same error, and I just noticed that your error log has the vue.esm-bundler.js version, so I don't know what's going on.

[an0nusr]

Hmm, production still errors out with the same error, and I just noticed that your error log has the vue.esm-bundler.js version, so I don't know what's going on.

I'm guessing it's related to --no-scope-hoist since that seems to be the difference between it working and it failing.

[RGdevz]

tried today parcel I like it better then vite, but I have this issue too

[npulidom]

This issue is similar to #7663.
A workaround is to use this resolver to force Parcel to use vue.runtime.esm-browser.prod.js version.

[an0nusr]

This issue is similar to #7663. A workaround is to use this resolver to force Parcel to use vue.runtime.esm-browser.prod.js version.

This seems to go against Vue's documentation which states that vue.runtime.esm-browser.prod.js is designed for CDN/in-browser use, while vue.esm-bundler.js is for people using bundlers (like Parcel), but still want in-html templating.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs.

[douglasg14b]

What is the resolution here? When I build my vue application for prod this appears to happen on any component that relies on runtime compilation.

TypeError: i.type is undefined
isAsyncWrapper runtime-core.esm-bundler.js:2454
unmount runtime-core.esm-bundler.js:6519
patchKeyedChildren runtime-core.esm-bundler.js:6399
patchChildren runtime-core.esm-bundler.js:6209
processFragment runtime-core.esm-bundler.js:5848
patch runtime-core.esm-bundler.js:5316
patchKeyedChildren runtime-core.esm-bundler.js:6295
patchChildren runtime-core.esm-bundler.js:6209
patchElement runtime-core.esm-bundler.js:5637
runtime-core.esm-bundler.js:259:12
logError runtime-core.esm-bundler.js:259
handleError runtime-core.esm-bundler.js:241
callWithErrorHandling runtime-core.esm-bundler.js:194
flushJobs runtime-core.esm-bundler.js:399
(Async: promise callback)
queueFlush runtime-core.esm-bundler.js:308
queueJob runtime-core.esm-bundler.js:302
effect runtime-core.esm-bundler.js:6136
resetScheduling reactivity.esm-bundler.js:264
triggerEffects reactivity.esm-bundler.js:308
triggerRefValue reactivity.esm-bundler.js:1070
set value reactivity.esm-bundler.js:1115
handleStepperChange CreateCampaign.vue:61
callWithErrorHandling runtime-core.esm-bundler.js:192
callWithAsyncErrorHandling runtime-core.esm-bundler.js:199
emit runtime-core.esm-bundler.js:712
set proxiedModel.mjs:37
set value reactivity.esm-bundler.js:1016
select group.mjs:137
toggle group.mjs:59
onClick VStepperItem.mjs:82
callWithErrorHandling runtime-core.esm-bundler.js:192
callWithAsyncErrorHandling runtime-core.esm-bundler.js:199
invoker runtime-dom.esm-bundler.js:681

[danbrellis]

I am also seeing this on Parcel v2.12.0.

In my case I have some vue SFC and some components that need the runtime compiler on the same page. Getting the same errors as @an0nusr and the --no-scope-hoist flag did indeed work as a work-around. Anyone get anywhere with this past the workaround?