next-optimized-images
next-optimized-images copied to clipboard
cyrilwanner
Having a file extension of JPG instead of JPEG (and vice versa) causes cryptic Webpack error (Error: write EPIPE)
https://github.com/cyrilwanner/next-optimized-images/blob/756bb958e91a0fdb4e51c8185733df224cda0678/lib/loaders/index.js#L80
If an image has the file extension of .jpg when it should be .jpeg, Webpack throws an incredibly cryptic error. To try this, take any .jpeg file, rename it with the .jpg extension, and try to run this package. You'll get a "write EPIPE" error, and a call stack that merely indicates that the problem is somehow related to this package.
I imagine that the issue goes deeper, with imagemin-mozjpeg, as next-optimized-images seems to handle jpg and jpeg files the same way. That is the bug. They should not be handled the same way, and the error should be thrown if a file has the wrong extension.
Here is a sample image file if you want to reproduce this.
Here's an example error stack: `
EnvironmentPlugin - undefined environment variable is undefined.
03:16:54 PM | You can pass an object with default values to suppress this warning.
03:16:54 PM | See https://webpack.js.org/plugins/environment-plugin for example.
03:16:54 PM | ./pages/leadership/photos/ari-mendelow.jpg
03:16:54 PM | Error: write EPIPE
03:16:54 PM | EnvironmentPlugin - undefined environment variable is undefined.
03:16:54 PM | You can pass an object with default values to suppress this warning.
03:16:54 PM | See https://webpack.js.org/plugins/environment-plugin for example.
03:16:54 PM | ./pages/leadership/photos/ari-mendelow.jpg
03:16:54 PM | Error: write EPIPE
03:16:54 PM | Automatically optimizing pages...
03:16:55 PM | router.query: {}
03:16:55 PM | data: undefined
03:16:55 PM | router.query: {}
03:16:55 PM | router.query: {}
03:16:55 PM | router.query: {}
03:16:55 PM | data: undefined
03:16:55 PM | Error: Module build failed (from ./node_modules/img-loader/index.js):
03:16:55 PM | Error: write EPIPE
03:16:55 PM | at WriteWrap.afterWrite [as oncomplete] (net.js:789:14)
03:16:55 PM | at Object.6tA3 (/zeit/d16e389/.next/serverless/pages/leadership.js:519:7)
03:16:55 PM | at webpack_require (/zeit/d16e389/.next/serverless/pages/leadership.js:23:31)
03:16:55 PM | at webpackContext (/zeit/d16e389/.next/serverless/pages/leadership.js:1661:9)
03:16:55 PM | at Leadership.keys_default.map.leaderKey (/zeit/d16e389/.next/serverless/pages/leadership.js:5820:39)
03:16:55 PM | at Array.map (next build
03:16:55 PM | npm ERR! Exit status 1
03:16:55 PM | npm ERR!
03:16:55 PM | npm ERR! Failed at the [email protected] build script.
03:16:55 PM | npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
03:16:55 PM | npm ERR! A complete log of this run can be found in:
03:16:55 PM | npm ERR! /zeit/.npm/_logs/2020-01-13T23_16_55_499Z-debug.log
03:16:55 PM | Error: Exited with 1
03:16:55 PM | at ChildProcess.child.on (/zeit/83f001be910e94ef/.build-utils/.builder/node_modules/@now/next/dist/index.js:47050:24)
03:16:55 PM | at emitTwo (events.js:126:13)
03:16:55 PM | at ChildProcess.emit (events.js:214:7)
03:16:55 PM | at maybeClose (internal/child_process.js:925:16)
03:16:55 PM | at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)
03:16:55 PM | worker exited with code 20 and signal null
03:16:58 PM | done
`
@arimendelow Were you able to find a workaround? I'm stuck with this exact issue as well. Would renaming all .jpg files to .jpeg help?
Good question, I don’t remember. Definitely worth giving it a shot and reporting back here!
I had a similar error regarding EPIPEs too, although the error message was not the same. The fix that worked for me was I directly published it from my own laptop via vercel-cli as the vercel website's build was causing this error. I'm not really sure of the details why that worked but I got a hint of that since my local build was working fine.
I had a similar error regarding EPIPEs too, although the error message was not the same. The fix that worked for me was I directly published it from my own laptop via vercel-cli as the vercel website's build was causing this error. I'm not really sure of the details why that worked but I got a hint of that since my local build was working fine.
That problem should be solved in the canary version as image optimization is moved to WebAssembly there and so it works exactly the same in every environment. If some of you still experience those issues, I recommend switching to canary as that solves a lot of the current problems. And it will move out of canary soon anyway.
Thanks @cyrilwanner ! Is there any other way around, as sprites are not supported yet in canary right?
@cyrilwanner I found it works on v2.6.2, which is stable. Can you check it out and close this issue as resolved?
