search

Niels-IO / next-image-export-optimizer

Use Next.js advanced <Image/> component with the static export functionality. Optimizes all static images in an additional step after the Next.js static export.
MIT License
460 stars 56 forks source link

Nested nextImageExportOptimizer folder for each image #100

Closed PeterKottas closed 1 year ago

PeterKottas commented 1 year ago

Just a small tidying-up suggestion. I noticed that next-image-export-optimizer would create an extra nextImageExportOptimizer folder for each image it generates. Example: extraFolders Seeing that these are generated and put into the public directory as well, you basically end with 2 copies in the source code. Since its caching them based on a hash, I think it's not unreasonable to commit the ones in the public directory to git, but the rest of them seems a bit redundant. Of course, these could be ignored by git ignore, but you still end up with a bunch of extra stuff in project folders locally. I can totally see how this makes things easier when implemented, but I thought it might be cleaner to commit these and use solely the ones in the public dir.

Niels-IO commented 1 year ago

Hi @PeterKottas, I am not 100% sure what you mean by duplicated? in the specified image folder, the library finds all image files and creates the optimized versions in this extra folder next to each image. There should not be any duplication happening.

Are you statically importing the images? I might have to add to the documentation that putting the images in the image folder is only necessary for dynamically specified images.

PeterKottas commented 1 year ago

Sorry, I might not have been clear. The duplication occurs when these images are copied to the public folder. So you end up with these (that you described) and then also the ones in public folder.

What would be more elegant I think is having a folder e.g. .nextImageExportOptimizer in the root of the project. Put all images there while generating (for caching purposes). Possibly even reconstruct the original folder structure to avoid problems with the same names. And leave the actual project folders alone. So as a result, no new content will be created in the specified image folder.

Look at my example, I have an assets folder that is a part of the project. But when navigating these extra folders creates a lot of visual buzz. Imagine each file processor including nextjs, typescript, babel, scss ..... would do this. You'd end up with a bunch of extra folders everywhere. Instead, the usual norm is to create some sort of .cache folder and use that. Actually if you for instance look at next, you'll see they have a '.next' folder, and inside is a 'cache' folder.

Are you statically importing the images? Yep

Hope this helps, unless I am of course missing something :D

Niels-IO commented 1 year ago

Hi @PeterKottas,

Thanks for the explanation; I get it now 🙂

I never tested the case where the image folder is outside the public directory. As the images outside the public directory can only be used via static import, the created nextImageExportOptimizer subfolders don't make any sense and should not be generated. Static images are taken directly from the next/static/media folder in the build folder generated by Next.js.

I fixed this behavior in this PR #106. You would have to delete these folders manually once, but they should not be generated again.

PeterKottas commented 1 year ago

Fantastic! Cheers man, I appreciate you fixing this so quickly.