Version 3

[cyrilwanner]

Background

This project started out as a small package. Over time, more and more features were added and it now provides many different things and is used by many developers. But I'm not 100% happy with the current version for the following reasons:

• it depends on many different webpack loaders which has led to some workarounds and many features cannot be combined because the loaders don't work well with each other. See Inlining resized images #84, webp srcset #91 for examples.
• those loaders also depend on other packages which have also introduced errors/bugs where we don't have the possibility to fix them directly (as in svg?sprite Cannot find module svg-baker-runtime/symbol.js #75).
• while this package grew, the installation and configuration became more and more complex and I think there is some space for improvement here.

Idea

To make this package robust for the future and easy to maintain, I think the only way is to fix those issues. And this probably requires a rewrite of the whole package.

It can be broken down into multiple parts:

Webpack loaders

This is the most important part of this package and is currently out of our control. To support use-cases such as mentioned in #84 or #91 and so we are able to provide a stable plugin, I think the only way is to write an own webpack loader which does the image optimizations. That would have the following advantages:

• all features work together (e.g. you can resize a jpg, convert it to webp and generate a lqip all at the same time, which is not possible right now)
• we have more control over the libraries used for image optimization (that part would of course still be a 3rd party library)
• it would be published as a separate loader and could also be used outside of a next.js project

Next.js plugin

This plugin would configure the independent webpack loader for easy use with next.js. It should also support the upcoming next.js plugin system for an easy installation.

Support run-time optimization

One of the most requested features was to be able to optimize images during run-time (e.g. from an API) and not only local images during build-time (see #104, #77, #74). With the API routes introduced in next.js 9, I think it should be possible to provide an easy-to-use service for that. It obviously can't relay on webpack, but the code used in the webpack loader should be reusable.
That would have the following advantages:

• it is possible to optimize images returned from an API/3rd party service
• they would have exactly the same optimization options and query strings so you can use them exactly the same as a local image

But this feature would need to be defined more detailed (e.g. it would need a store, like S3, so images are not optimized on every request, and this API would be best located behind a CDN, etc.).

Provide image components

Creating an image component is not easy, especially if you want to support all features of this plugin (webp fallback, lqip, srcset, ...). And you still have to think about what happens when JS is disabled (while lazy loading), how it has to be optimized for screen readers and search engines and so on. So if you want your images to be working well for everyone, it is not just <img src={require('./image.jpg')} />, there is a lot more work to do and you don't want to do this again in every project.

So I'm thinking about providing an image component that will work well with this plugin and already does most of the things for you (non-JS fallback, a11y, lazy loading with fallbacks, ...).

It should support the following things:

• webp with fallbacks for old browsers (see WebP auto fallback #111)
• lazyloading using either a low quality image placeholder (Blur Up), Image Outlines or Dominant Colors

Additionally, it would be nice to provide a babel plugin which makes it even easier to use this component.
So instead of this:

<Img
  src={require('./image.jpg')}
  sizes={{
    100: require('./image.jpg?resize&size=100'),
    300: require('./image.jpg?resize&size=300'),
    600: require('./image.jpg?resize&size=600')
  }}
  lqip={require('./image.jpg?lqip')}
/>

You would only use it like this and the babel plugin will transform it to the way more complex way above:

<Img src={require('./image.jpg')} sizes={[100, 300, 600]} lqip />

Feedback wanted

I am of course open to any feedback on any part of this idea. Also, if you have ideas of new features, now would be the time as they could be included from the beginning of the new version.

I am not quite sure on which image optimization library this should be based on. Right now, it is mainly imagemin but I am not really happy with it since it is not easy to install, especially in some CI/CD environments since it requires specific binaries to be installed on the system.
So I was thinking about using sharp as the main optimization library as it is a lot easier to install, has a great node API and is still quite fast compared to other node libraries.

Feedback on this would be very appreciated, especially:

• has someone made experiences with both libraries? (regarding speed, simplicity, ...)
• would you switch to another library?
• if the decision falls for sharp, should imagemin (or others) also be additionally supported?

Is there an ETA?

No, development has started but is in the early stages. The features mentioned above are quite complex and require a lot of work, so it will probably take some weeks. But I will update this issue when progress is made and when a canary version is available.

[AleVul]

Could i suggest to use wasm for the optimization part. Squoosh uses wasm to compress images, for example this lib

[cyrilwanner]

That's a good idea @AleVul, thanks! That would solve the problem with native binaries needed. I'll definitely check this option out 👍

[akd-io]

Sounds awesome @cyrilwanner, are you still pursuing this?

I think this project is important and would love to see it flourish. I have no experience with Webpack stuff, but let me know if you need help with any laborious tasks or more general JS/TS parts of the library.

[merelinguist]

Eagerly awaiting this! 😄

[andyfangaf]

Remote image optimization would be amazing. 🎉

[cyrilwanner]

I'm sorry for the long silence on this issue. I just didn't have much time to work on this over the last few months, unfortunately.
But yes, all this is still planned and will come.
Last week, I started to work on this issue again so I'll hopefully be able to share some progress soon.

Currently, I'm working on compiling the different image optimization tools into WebAssembly so we are able to make the whole installation (especially in a CI/CD environment) a lot easier and more consistent. Squoosh, unfortunately, doesn't provide their compiled WASM binaries as packages, but I'm slowly getting there.
That's probably the biggest and most time-consuming part. So once that is done, the other features are way easier to implement.

[akd-io]

Super cool Cyril, best of luck! 💪

[jasonsilberman]

I saw your message on the Next.js discussions board and posted a message in response to another user's questions with how I did something like this. I'd be happy to help out or give a few pointers with how I implemented something like this!

[cyrilwanner]

Hi @jasonsilberman and thank you very much!
I'm currently still on the foundation for all those new features, but I'll come back to you when it is ready and the remote image optimization can get implemented as I saw in your comment that you already did some work in that area.

But I already have a few initial questions, if you would like to give some insights.
It looks like the images get resized during upload and not on-the-fly when they get requested, is that correct? Also, did you deploy this into a cloud/serverless environment? If so, did you encounter any issues with sharp? Or any other things we should already consider or think about when planning/implementing this feature?
Thanks for your help!

[tilman]

Hey, really looking forward to the new Version! In the meantime I had the need for an Image Component by myself so I created one and shared it here:
https://github.com/tilman/next-optimized-image-component

It's still WIP but supports:

• lqip image placeholder, blurred with SVG filter for best compatibility
• blur radius adapts automatically based on the image size. Because we can't determine displayed image size in SSR, it is animated to this radius from a default radius of 40px
• If the IntersectionObserver API is available, it only starts loading the image if it is near the viewport
• use all height/width combinations for the Img component and the component will take care about placing the lqip exactly over the image
• use webp as picture source by default with fallback for older browsers
• also supports a no javascript fallback

Since you wrote, you want to provide an Image Components as well, I thought it's maybe interesting for you.

[truongsinh]

Feedback on provided component:

Instead of using babel transform, we can use gatsby-image strategy. Something like this:

class Lquip {
  imgSrc: string;
  blur: number;
}
class LquipColor {
  backgroundColor: string;
}
class Trace {
  imgSrc: string;
}
interface ResponsivePictureElement extends DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement> {
  resources: {
    sources: DetailedHTMLProps<SourceHTMLAttributes<HTMLSourceElement>, HTMLSourceElement>[]
    fallbackSrc: string;
    placeholder?: Lquip | LquipColor | Trace;
    intrinsicWidth: number;
    intrinsicHeight: number
  }
}

export function Picture(props: ResponsivePictureElement) {
  const { resources: { sources, fallbackSrc, placeholder, intrinsicWidth, intrinsicHeight } } = props;
  let { style } = props
  if (placeholder instanceof Lquip) {
    // TODO can `filter` be applied to `backgroundImage` ?
    style = { ...style, backgroundImage: `url('${placeholder.imgSrc}')`, filter: `blur(${placeholder.blur}px)` }
  } else if (placeholder instanceof LquipColor) {
    style = { ...style, backgroundColor: placeholder.backgroundColor }
  } else if (placeholder instanceof Lquip) {
    style = { ...style, backgroundImage: `url('${placeholder.imgSrc}')` }
  }
  style = { ...style, height: intrinsicHeight, width: intrinsicWidth }
  return <picture {...props} style={style}>
    {sources.map((r) => <source
      srcSet={r.srcSet}
      media={r.media}
      sizes={r.sizes}
      type={r.type}
      {...r}
    />)}
    <img src={fallbackSrc} />
  </picture>
}

usage

<Picture resources={require('./myimage.png')} />
<Picture resources={require('./myimage.png?trace&resize&size[]=300&webp')} />

The 2 above can be equivalent with preset in the config.

WDYT?

[jasonsilberman]

Hi @jasonsilberman and thank you very much!
I'm currently still on the foundation for all those new features, but I'll come back to you when it is ready and the remote image optimization can get implemented as I saw in your comment that you already did some work in that area.

But I already have a few initial questions, if you would like to give some insights.
It looks like the images get resized during upload and not on-the-fly when they get requested, is that correct? Also, did you deploy this into a cloud/serverless environment? If so, did you encounter any issues with sharp? Or any other things we should already consider or think about when planning/implementing this feature?
Thanks for your help!

You are right, I am processing images on upload and not on the fly. I did this because we host the images on Google Storage (with a CDN in front) and so we could not easily do resizing on the fly. Additionally, this is for a static site and we know all of the images dimensions ahead of time, so we could pre-cut all of the exact images we needed.

We have deployed our image pipeline to a serverless environment, Vercel. I have not experienced any issues with using Sharp on Vercel's platform as of yet. The one thing to be consider is that you can only write to a /tmp folder on Vercel, and so you could not save images to disk. We use the readStream and writeStream APIs so this was not an issue for us.

Hope this helps.

---

Some other thoughts on the plugin in general:

• I think it would be important that you can download/upload images to S3 or other cloud providers. As this would allow images to be served over CDN, or perhaps use already uploaded user-content as your image.
• I appreciate that you are making sure to take into considerations the accessibility, performance, and SEO implications of this plugin. I think this is also important for today's websites.
• Lastly, while Gatsby's tools only work at build-time because of the nature of Gatsby, it would be great if we could find a way to make this work on both static and dynamic sites. I agree that it seems API Routes (for serverless deployments) or some middleware that could be used with custom servers would be ideal!

Anyway, I'm excited about the development of this plugin!

[brandonpittman]

I surprised Vercel hasn't built an image component yet. They have ones for head and link. 🤔

[harrisrobin]

+1, a nextJS version of gatsby-image would be amazing ✨

[liran]

Any progress on this?

[paambaati]

@cyrilwanner next-optimized-images has been an absolute life-saver, so thanks for the project.

FWIW, I recently found next-img, a somewhat similar project by @kidkarkolis. It offers a few unique things like a build cache; you might want to check it out for some inspiration.

[cyrilwanner]

@paambaati glad to hear that!

I've seen that package too. And as a small update to the current state: I'm actively working on the version 3 and the first canary version is just a few days away.
(I couldn't invest too much time recently since I have university exams over the next two weeks, but I think I should still get the canary version out this weekend. And after those two weeks, I'll work full-time on this package until everything is ready and released)
And I can just say that all the features that package provides (and even more) are already done and will be available in the canary version. The build cache (and so way faster dev builds with optimized images) is just one of them.

I'll of course post here once the canary version is published to npm.

(And I've split this project into multiple modular packages, like one for the WebAssembly codecs, one for the webpack loader, one for the components and this which binds all together, so it could basically also be used outside of a next.js project. That's the reason why you don't see much going in in this repository. The other repositories will of course also made public when they are ready, but they are currently lacking a bit of documentation)

[cyrilwanner]

It was a lot of work and there is still a lot to do, but the first canary version is now available 🎉

Not all planned features are already available. The remote image optimization & lazy loading components (like blur-up) are missing. But they are still planned and will get added soon to the canary version.
Other than that, I think most of the planned features are now done and stable.

Some of the new features are:

• Image optimization is performed either in node or WebAssembly - there is no need for imagemin plugins anymore and so no native binaries are required (= works in every environment out of the box)
• Build cache for images - results in way faster builds and images are also optimized in the dev environment by default
• Image components are provided for even easier use - there shouldn't be a need to use query params anymore normally (a babel plugin does that now for you)
• images.config.js for global configuration and definition and re-use of image types and their options
• Full typescript support thanks to the provided image components
• Query params can be chained now - for example ?webp&width=400
• ...and more. Read the readme file for an overview of all features.

I suggest you check out the readme on the canary branch for more details.

---

Any feedback, further ideas, or bug reports are of course very much appreciated and will help to bring the canary version to the @latest tag faster. The babel plugin for the image components probably doesn't recognize 100% of all use-cases, so if you find any, please share them if possible.

I would be very happy if some of you could test the canary version and report back if something is not working. Or if some of you have open-source projects using this package, it would already help if you can share them with me so I can see if there are some use-cases I did not think about and try it myself to update next-optimized-images to the canary version.

Also, if you find anything unclear in the readme or upgrade guide, don't hesitate to ask. It was already late when I wrote there so it is possible that not everything is 100% is explained well enough.

---

If you want to update this plugin in an existing project, please read the upgrading guide guide as some breaking changes were introduced.

Also, not yet all features previously available are already in the canary version. If your project depends on one of the following features, you may have to wait a few more days until they were ported into the new version:

• Gif optimization (gif images can be used normally, they just don't get optimized)
• ?trace query param
• ?sprite query param

---

And thank you all for your continued support and feedback. I understand that it took a long time to get to this point, but I'm very happy with the result and think that it was worth it. And the remaining todos won't take that long anymore.

[andyfangaf]

Great work @cyrilwanner, I've given v3 a test and will look out for issues and reference them here. Might be a better way to track the v3 issues though.

#164 (having trouble building).

[danielr18]

The babel plugin does not currently recognize styled components like the one below:

import styled from '@emotion/styled';

S.Image = styled(Img)({
  width: '100%'
});

[cyrilwanner]

Thank you for already testing it!

I've given v3 a test and will look out for issues and reference them here. Might be a better way to track the v3 issues though.

Yes I agree, that may be the better way to track issues 👍

The babel plugin does not currently recognize styled components like the one below:

import styled from '@emotion/styled';

S.Image = styled(Img)({
  width: '100%'
});

That is something I completely forgot about as I'm not using that in my projects. Perfect that you could test that, thank you. I'll of course add support for styled components.

[yanmezinskiy777]

Hey, really looking forward to the new Version! In the meantime I had the need for an Image Component by myself so I created one and shared it here:
https://github.com/tilman/next-optimized-image-component

It's still WIP but supports:

• lqip image placeholder, blurred with SVG filter for best compatibility
• blur radius adapts automatically based on the image size. Because we can't determine displayed image size in SSR, it is animated to this radius from a default radius of 40px
• If the IntersectionObserver API is available, it only starts loading the image if it is near the viewport
• use all height/width combinations for the Img component and the component will take care about placing the lqip exactly over the image
• use webp as picture source by default with fallback for older browsers
• also supports a no javascript fallback

Since you wrote, you want to provide an Image Components as well, I thought it's maybe interesting for you.

I have a bug in component =( if I use Img component in div with onClick={...}

[paambaati]

@cyrilwanner 👋 Just checking in, and I wanted to bring to your notice the impending release of Webpack 5. As next-optimized-images relies heavily on Webpack, I wanted to understand how much effort it would take for v3 to support Webpack 5. Next.js's Webpack 5 compatibility is also close to complete.

[meienberger]

I also have the warnings for the max listeners. Unfortunately setting maxListener to any number doesn't solve my issue. I have no problem on my local machine. The issues comes when I try to deploy on Vercel :

RangeError: WebAssembly.Memory(): could not allocate memory

15:14:26.163	RangeError: WebAssembly.Memory(): could not allocate memory
15:14:26.164	RangeError: WebAssembly.Memory(): could not allocate memory
15:14:26.167	/vercel/6d54a8a7/node_modules/@wasm-codecs/mozjpeg/lib/mozjpeg.js:9
15:14:26.167	var Module=typeof mozjpeg!=="undefined"?mozjpeg:{};var moduleOverrides={};var key;for(key in Module){if(Module.hasOwnProperty(key)){moduleOverrides[key]=Module[key]}}var arguments_=[];var thisProgram="./this.program";var quit_=function(status,toThrow){throw toThrow};var ENVIRONMENT_IS_WEB=false;var ENVIRONMENT_IS_WORKER=false;var ENVIRONMENT_IS_NODE=false;var ENVIRONMENT_HAS_NODE=false;var ENVIRONMENT_IS_SHELL=false;ENVIRONMENT_IS_WEB=typeof window==="object";ENVIRONMENT_IS_WORKER=typeof importScripts==="function";ENVIRONMENT_HAS_NODE=typeof process==="object"&&typeof process.versions==="object"&&typeof process.versions.node==="string";ENVIRONMENT_IS_NODE=ENVIRONMENT_HAS_NODE&&!ENVIRONMENT_IS_WEB&&!ENVIRONMENT_IS_WORKER;ENVIRONMENT_IS_SHELL=!ENVIRONMENT_IS_WEB&&!ENVIRONMENT_IS_NODE&&!ENVIRONMENT_IS_WORKER;var scriptDirectory="";function locateFile(path){if(Module["locateFile"]){return Module"locateFile"}return scriptDirectory+path}var read_,readAsync,readBinary,setWindowTitle;var nodeFS;var nodePath;if(ENVIRONMENT_IS_NODE){scriptDirectory=dirname+"/";read=function shell_read(filename,binary){if(!nodeFS)nodeFS=require("fs");if(!nodePath)nodePath=require("path");filename=nodePath"normalize";return nodeFS"readFileSync"};readBinary=function readBinary(filename){var ret=read(filename,true);if(!ret.buffer){ret=new Uint8Array(ret)}assert(ret.buffer);return ret};if(process["argv"].length>1){thisProgram=process["argv"][1].replace(/\/g,"/")}arguments_=process["argv"].slice(2);process["on"]("uncaughtException",function(ex){if(!(ex instanceof ExitStatus)){throw ex}});process"on";quit_=function(status){process"exit"};Module["inspect"]=function(){return"[Emscripten Module object]"}}else if(ENVIRONMENT_IS_SHELL){if(typeof read!="undefined"){read_=function shell_read(f){return read(f)}}readBinary=function readBinary(f){var data;if(typeof readbuffer==="function"){return new Uint8Array(readbuffer(f))}data=read(f,"binary");assert(typeof data==="object");return data};if(typeof scriptArgs!="undefined"){arguments_=scriptArgs}else if(typeof arguments!="undefined"){arguments_=arguments}if(typeof quit==="function"){quit_=function(status){quit(status)}}if(typeof print!=="undefined"){if(typeof console==="undefined")console={};console.log=print;console.warn=console.error=typeof printErr!=="undefined"?printErr:print}}else if(ENVIRONMENT_IS_WEB||ENVIRONMENT_IS_WORKER){if(ENVIRONMENT_IS_WORKER){scriptDirectory=self.location.href}else if(document.currentScript){scriptDirectory=document.currentScript.src}if(scriptDir){scriptDirectory=scriptDir}if(scriptDirectory.indexOf("blob:")!==0){scriptDirectory=scriptDirectory.substr(0,scriptDirectory.lastIndexOf("/")+1)}else{scriptDirectory=""}{read=function shell_read(url){var xhr=new XMLHttpRequest;xhr.open("GET",url,false);xhr.send(null);return xhr.responseText};if(ENVIRONMENT_IS_WORKER){readBinary=function readBinary(url){var xhr=new XMLHttpRequest;xhr.open("GET",url,false);xhr.responseType="arraybuffer";xhr.send(null);return new Uint8Array(xhr.response)}}readAsync=function readAsync(url,onload,onerror){var xhr=new XMLHttpRequest;xhr.open("GET",url,true);xhr.responseType="arraybuffer";xhr.onload=function xhr_onload(){if(xhr.status==200||xhr.status==0&&xhr.response){onload(xhr.response);return}onerror()};xhr.onerror=onerror;xhr.send(null)}}setWindowTitle=function(title){document.title=title}}else{}var out=Module["print"]||console.log.bind(console);var err=Module["printErr"]||console.warn.bind(console);for(key in moduleOverrides){if(moduleOverrides.hasOwnProperty(key)){Module[key]=moduleOverrides[key]}}moduleOverrides=null;if(Module["arguments"])arguments=Module["arguments"];if(Module["thisProgram"])thisProgram=Module["thisProgram"];if(Module["quit"])quit_=Module["quit"];function dynamicAlloc(size){var ret=HEAP32[DYNAMICTOP_PTR>>2];var end=ret+size+15&-16;if(end>_emscripten_get_heap_size()){abort()}HEAP32[DYNAMICTOP_PTR>>2]=end;return ret}var asm2wasmImports={"f64-rem":function(x,y){return x%y},"de
15:14:26.167
15:14:26.170	RuntimeError: abort(RangeError: WebAssembly.Memory(): could not allocate memory). Build with -s ASSERTIONS=1 for more info.
15:14:26.170	at process.abort (/vercel/6d54a8a7/node_modules/@wasm-codecs/mozjpeg/lib/mozjpeg.js:9:10196)
15:14:26.170	at process.emit (events.js:327:22)
15:14:26.170	at processPromiseRejections (internal/process/promises.js:209:33)
15:14:26.170	at processTicksAndRejections (internal/process/task_queues.js:98:32)
15:14:26.364	error Command failed with exit code 7.
15:14:26.364	info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
15:14:26.374	Error: Command "yarn run build" exited with 7

[malcolm-kee]

@cyrilwanner Just tried out canary with Next v10 and it works great for me!

Awesome work!

[jpmasud]

Same issue as @DonovanCharpin

[nicholaschiang]

@cyrilwanner I'm not sure if you've addressed this elsewhere, but what's the main difference between this project and the new Next.js built-in image optimization?

[lokmanm]

@nicholaschiang I am going to try to explain, hopefully @cyrilwanner can be more thorough.

Next.js built-in image optimization works only with an API ( as in serverless ) and the images are not generated in build time, this also means outside of Vercel you cant use them ( for now ). This package optimizes the images in build time so you have them ready to use post-build.

[nicholaschiang]

Yup, I figured as much but was wondering if there were any other differences. Right now, this package is great for build-time optimization (e.g. when you have a fixed number of static images) but can't easily be used with user-uploaded images.

I noticed in this RFC that you're thinking of adding runtime optimization features and was wondering why (because Next.js 10 already has them built-in).

[maxwolfs]

I also have the warnings for the max listeners. Unfortunately setting maxListener to any number doesn't solve my issue. I have no problem on my local machine. The issues comes when I try to deploy on Vercel :

RangeError: WebAssembly.Memory(): could not allocate memory

I have the same issue with the Vercel Deployment. @meienberger Have you found any workaround/solution in the meantime?

[meienberger]

@maxwolfs I could not find a solution and I moved to a server based solution. Maybe you can try with Next v10 if you are not already there

[james-wallis]

I ran into the same error that @meienberger had.

I was able to get past it (not solve) by:

1. Removing the sizes and breakpoints from each <Img> tag
2. Attempting to make all the file paths static e.g. import MyImage from './myimage.jpg as opposed to <Img src={require('./${myImageJpgVar}')} />.
3. In cases where I needed to use dynamic files I placed them in their own directory.

Note: I only have 20 or so images

I know that this "solution" isn't great but it enabled me to build my Next.js app once again. FYI it also successfully built on Vercel.

Using:

"next": "latest",
"next-optimized-images": "^3.0.0-canary.10",

[enpclark]

I couldn't find a way to add style props to the Picture element of the component. All styles are handed down to the img element. is this intentional?

[davecardwell]

@enpclark With a <picture> element you always put the style, alt, etc. attributes on the <img> (as in, that is the norm with the HTML, regardless of this library).

[osdiab]

I just tried this out and it's mostly pretty good! But I'm wondering why the use of picture element instead of just using the srcset property on an img element if the generated images are all going to be the same but just different sizes/densities. I got frustrated because replacing the img element with a picture element makes it trickier to style correctly, because of the extra nesting of the HTML which makes stuff like flexbox rules from the image's parent fall on their face in certain contexts.

My understanding is that picture is more intended for art direction problems, not for what can be accomplished with just a simple srcset - would you consider making the picture semantics be a separate abstraction than just the bare Img component or opt-in somehow? It's not necessary for the vast majority of use cases I have and is making my styling a pain.

[TheThirdRace]

Is this V3 still happening?

I haven't seen any comments from @cyrilwanner since Aug 12th 2020.

No commit have been made since Aug 9th 2020.

I hope it's not been cancelled because NextJs launched their own image optimization solution. NextJs solution is far from perfect and has plenty of troubles:

• Caching is forcing network request to check Etag, you can't override this behavior
• Optimization is done on the fly, which means it's a delay you wouldn't get at build time
• The image styling used is highly restrictive, inefficient and forces the use of !important to overwrite
• Most uses of Next/Image component results in 3 to 4 DOM nodes per image, which is simply atrocious
• The wrappers are DIVs, so if you use in a P tag, you're semantically incorrect
• You can't use a decent Content-Security-Policy header

As you can see, we do need an alternative because NextJs solution isn't rosy as soon as you dig a little deeper.

[davecardwell]

Is this V3 still happening?

I second @TheThirdRace’s thoughts on the new built-in Next.js solution and would very much like to continue using next-optimized-images v3.

I appreciate @cyrilwanner may have moved onto other priorities—that’s the nature of open source some times, and I thank him for his efforts thus far. It would be good to hear whether or not this library is likely to see any further development though so we can make alternative arrangements.

[FreedomBen]

Thanks for bringing this up, I was wondering the same thing. I don't currently have (and I don't want to have) node at all in production, so I can't use the Next.js solution.

Is anybody using this canary version? Is it ready for release or does it still have open issues?

[Rigel772]

Mayby @cyrilwanner should update the module status...

[osdiab]

@FreedomBen I'm using it on a small project and it seems stable enough but I too am concerned there's no development here anymore. Maybe a fork would be good if someone is interested to maintain.

[samuelcastro]

Is this still happening @cyrilwanner? Your feedback here would really appreciated.

[Emiliano-Bucci]

So this library is dead?

[KrDimitrov]

Let us know if you are looking for maintainers @cyrilwanner. Im sure there are people who are happy to help!

[Develliot]

I'm also eagerly awaiting V3

Also I love the fact that with each deploy the image is placed in cache with a new hashed file name, so each deploy I get fresh images I don't have to wait for the cache to expire for users to see new version of the same image file.

Also I'm not using Vercel to deploy I've got my own AWS CDK configuration so I have no idea if the Next image caching strategies are even going to work with me and my AWS CDK deployment at run time.

[Emiliano-Bucci]

@cyrilwanner ?

[einSelbst]

I think I saw on twitter that he's busy with his thesis or something. Eventually priorities will shift after that and all the nice tools he made will flourish again :)

[TheThirdRace]

It's perfectly ok to be busy, very understandable and we can all relate to that.

It would be nice if he could take 10 minutes and put a big message at the top of the Readme file on the repo so people stop asking the same question 😅

[ranaharoon3222]

@cyrilwanner any progress can i use in production?

[framp]

Great job so far on the canary and the library is very much appreciated.

The only bug I found is that inlining svg and converting them to webp causes the base64 encoded svg to be included instead of the webp one

<source type="image/webp" srcset="BASE64_SVG">

[machineghost]

It seems like this project is dead anyways, but I thought I'd ask ... given that Next itself has switched from Babel to Rust, is making Babel a requirement of v3 wise?