Open baffalop opened 7 months ago
Update: I was mistaken about versions. My ^3.3.4
actually resolved to 3.4. When I pin both vue
and @vue/compat
to ~3.3.4
the issue goes away. This fits with https://github.com/vuejs/core/issues/10148 which reports the error as only present on 3.4, not 3.3.
Is there any update on this issue further, I am also getting this issue in my project.
The problem is caused by incompatible dependency versions, Vue
depends on entities:^4.5.0
, but there are other packages that depend on entities:^2.2.0
, for some reason the dependency installed by yarn
is only entities:^2.2.0
, which leads to runtime errors.
I tried to use npm, pnpm
to install the dependency is not error, just for reference.
usually I don't express any emotion... and pleas don't get me wrong I don't mean to blame anyone. I came to this issue because of:
[nuxt] [request error] [unhandled] [500] decode_js.EntityDecoder is not a constructor
at new Tokenizer (./.output/server/chunks/routes/renderer.mjs:15285:28)
at ./.output/server/chunks/routes/renderer.mjs:16986:19
at ModuleJob.run (node:internal/modules/esm/module_job:262:25)
at async onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:482:26)
at async Object.handler (./.output/server/chunks/runtime.mjs:2986:19)
at async Server.toNodeHandle (./.output/server/chunks/runtime.mjs:3256:7)
which - out of a sudden - spits out after a fresh docker build of a nuxt project opting in to enable vue runtime compiler and... yes, of course working fine on local dev with node 20.12.2 but not with docker build. All builds (2 years+) without that compile()
part of the project went well over node versions 18 to 22...
So:
the error remained the same, the line (with context) reads like:
{
this.entityDecoder = new decode_js.EntityDecoder(
decode_js.htmlDecodeTree,
(cp, consumed) => this.emitCodePoint(cp, consumed)
);
}
with (line 1483):
var decode_js = require$$1;
aha, now... what?
how much abstraction is going on here - and causing confusion. All I wanted is to transfere a <image id="123"/>
to <img src="https://..../123/img.webp" />
with a vue component buried in nuxt project recieving that tag as string from a database.
God knows I am a big advocate for js and vue (in favor of react) or nuxt (in favor of next) etc. - but this time I wich to be writing perl cgi as we did 20years ago. 10min done.
...sorry no rant at all just frustration. Hope to find solution by myself over the weekend.
...for reference (as @lzl0304 stated) the output of pnpm why entities -r
shows a mix of entities@4.5.0 and entities@2.1.0
why.txt
HA! removed all and every package that required an `entities? version < 4.5 (thanks again @lzl0304) and violá build & run works as I were running local dev in production... conclusion?
monorepos have a limit when trying to mix legacy and modern packages. Stick to single repos in that case - cheers! (hope, this helps anyone stucked similar)
came here from https://github.com/vuejs/core/issues/10148 (for ref)
Vue version
3.4.21 (with @vue/compat 3.4.21)
Link to minimal reproduction
https://stackblitz.com/edit/vue2-jest-8qoex3?file=jest.config.js&view=editor
Steps to reproduce
What is expected?
I would like to run unit tests with Vue Test Utils, while on the migration build. My application has Vue 2 dependencies which cause unit tests to fail when they are run with Vue 3. I would expect to be able to use the migration build to fix this by aliasing
vue
to@vue/compat
viamoduleNameMapper
. (This is the approach recommended by vue-test-utils-compat though the minimal reproduction uses latest@vue/test-utils
.)What is actually happening?
Running tests with
moduleNameMapper: { '^vue$': '@vue/compat' }
causes the following TypeError:System Info
Any additional comments?
This is the same error as in https://github.com/vuejs/core/issues/10148 though it doesn't affect me at build- or runtime, only in Jest.