vinxi: [Issue][unplugin-imagemin] Plugin is not working
ref : https://github.com/nksaraf/vinxi/issues/44 repro : https://github.com/qlaffont/test-cmp
> test-cmp@ build /home/quentin/Documents/dev/test/test-cmp
> vinxi build
vinxi 0.0.60
start {
appRoot: './src',
ssr: false,
islands: false,
server: { base: undefined },
solid: {}
}
vinxi Found vite.config.js with app config
┌────────────────────────────┐
│ ⚙ Building your app... │
└────────────────────────────┘
removing /home/quentin/Documents/dev/test/test-cmp/.vinxi/build/ssr
removing /home/quentin/Documents/dev/test/test-cmp/.vinxi/build/client
removing /home/quentin/Documents/dev/test/test-cmp/.vinxi/build/server-fns
┌───────────────────────────────┐
│ 📦 Compiling ssr router... │
└───────────────────────────────┘
vinxi building router ssr in handler mode
vite v4.5.0 building SSR bundle for production...
"createHandler" is imported from external module "h3" but never used in "node_modules/.pnpm/vinxi@0.0.60_rollup@3.29.4_terser@5.26.0/node_modules/vinxi/runtime/server.js".
✓ 40 modules transformed.
.vinxi/build/ssr/manifest.json 1.40 kB
.vinxi/build/ssr/assets/index-fb87c914.css 46.63 kB
.vinxi/build/ssr/_...404_.js 0.74 kB
.vinxi/build/ssr/about.js 0.96 kB
.vinxi/build/ssr/assets/components-86ea9901.js 1.20 kB
.vinxi/build/ssr/index.js 3.61 kB
.vinxi/build/ssr/ssr.js 6.50 kB
[unplugin-imagemin] 📦 📦 Process start with Mode sharp
✓ built in 743ms
✔ build done 7:01:06 AM
┌──────────────────────────────────┐
│ 📦 Compiling client router... │
└──────────────────────────────────┘
vinxi building router client in build mode
[
'#vinxi/handler/client',
'/home/quentin/Documents/dev/test/test-cmp/src/routes/[...404].tsx?pick=default&pick=$css',
'/home/quentin/Documents/dev/test/test-cmp/src/routes/about.tsx?pick=default&pick=$css',
'/home/quentin/Documents/dev/test/test-cmp/src/routes/index.tsx?pick=default&pick=$css'
]
plugin-legacy overrode 'build.target'. You should pass 'targets' as an option to this plugin with the list of legacy browsers to support instead.
vite v4.5.0 building for production...
virtual:#vinxi/handler/client (1:106) "default" is not exported by "src/entry-client.tsx", imported by "virtual:#vinxi/handler/client".
✓ 115 modules transformed.
node:internal/process/promises:288
triggerUncaughtException(err, true /* fromPromise */);
^
[Error: ENOENT: no such file or directory, open '/home/quentin/Documents/dev/test/test-cmp/.vinxi/build/client/_build/assets/_...404_-legacy-ca63b2ec.js'] {
errno: -2,
code: 'ENOENT',
syscall: 'open',
path: '/home/quentin/Documents/dev/test/test-cmp/.vinxi/build/client/_build/assets/_...404_-legacy-ca63b2ec.js'
}
Node.js v18.17.1
ELIFECYCLE Command failed with exit code 1.```
About this issue
- Original URL
- State: open
- Created 6 months ago
- Comments: 17 (9 by maintainers)
hi
I have time to reply to this question now. Thank you for all your discussions and comments.
Let me answer some of the questions mentioned above.
In vite, we usually use the following ways to introduce image resources.
Import img from'. / a.png'. // Will be loaded as a module< img: src= ". / a.png" / >. // It is not usually loaded as a module.In css file.// Will not be loaded as a moduleUsually we use these ways to load our image resources.
But in fact, the second and third are not loaded by vite as modules, which leads to normal, for example, if we introduce it in a html now, it will not be built as a module in load or other hooks.
But in the second case, we are usually treated as a module by the plug-in so that vite can load it, such as the vue plug-in.
In the third case, the css file will not be treated as a module.
That’s why I need to distinguish between beforeBundle and then replace the whole css with rules after the last rendersource to achieve the effect.
At present, the solid plugin look like does not implement the second way to load the module,(I haven’t had time to check the implementation of solid yet.) so the situation of img src is not loaded as a module.
Due to the complexity of the current project caused by beforeBundle and squoosh and sharp svgo, and the confusion of the code, I recently have time to ReFactor the logic of the entire render, and I will also see if other implementations have a way to load all possible ways to load img as a module.
Thank you again for your reply.
Can we just fork it and patch it for now and release it under @vinxi namespace … this image optimizations stuff is probably important enough
Will take a look!