The Image/img fiasco really pulled the covers off for vercel for me. I have migrated all my work off of the platform.
NextJS’ lint strategically dissuades you from using the img tag in favor of the NextJS Image component. If you make the mistake of heeding this advice and migrating to it, you can’t use static site generation—which means you are stuck using their hosting.
Here’s one of the most PR-shameful threads I’ve ever read in OSS:
Lol, silently* replacing the original request with the company response instead of documenting it in the docs is certainly a move. Nice to have all the thumbs-up and heart reactions on the "sorry we don't do it", for sure. Love the "We'd love to hear your feedback" and then locking the discussion too. Not having the feature is one thing, but why not properly document that and the (by now existing) workarounds?
* yes, not 100% silent, there is a small gray indicator from Github that it has been edited, but one would not expect a full-on replace with that.
You are talking about exporting app more precisely, which outputs a bunch of HTML files (vs using SSG for only some pages).
You can keep the Image tag around very easily, there is an option to treat it as normal img tag, so no it doesn't block exporting, and I've tested it to confirm. Use an environment variable to enable or disable exporting.
Edit to add reference: https://nextjs.org/docs/api-reference/next/image#unoptimized
The last comment by @leerob which comes 2 years after the issue was opened, saying "we hear you" and "up-voting the issue is the best way for us to track that" just shows how empty their statements are, devoid of any intention do something about it. Very unprofessional behavior.
Can’t you adjust your config to serve the images using your own cdn with the Image component? By default maybe it’s vercel-friendly, but I recall it being trivial to adjust to use any other path instead.
Has this changed?
You could also modify the linting rules to exclude the Image rule.
Not saying vercel is awesome. I no longer use their products. I just didn’t find this particular matter to be problematic.
I haven't used the Image component but I've hosted a Next.js project. leerob's comment said "To clarify again, you do not need to use Vercel for optimizing images. It works using next start or any loader of your choice.". This implies that it would still work in SSR using any hosting method, it doesn't mean you're forced to use Vercel's hosting services.
There should be a warning that it won't work with SSG and is only for SSR, but there are also many features on next.js that are SSR only.
Does the <Image> tag work with the docker container? GP's issue is with how vercel was pushing the <Image> tag a lot yet it doesn't work when in static site generation mode which is used by a lot of people.
It doesn't work in SSG, no, but it works in SSR just as if you hosted on Vercel itself. That's what I do, SSR instead of SSG, because for my app the distinction is unnecessary if I'm hosting it myself.
It's 2023 what kind of plebeian is using raw image tags? NextJS's OSS design is exactly what it should be, I want the image tag. I don't want Vercel boxing me into a choice:
1. Serving images over Node.
2. Using Vercel.
I also don't want to eject code that is sitting right there in the repo. And I don't want to maintain a fork of a homebrew reimplementation of it.
I didn’t know they have a Next.js Docker image. Why do we specifically need theirs? I roll my own based on node:lts-alpine via GitHub Actions and push it to my Docker registry on GitHub.
You don't but it makes productionizing easy, I just have to pull their latest image for every build and it should work, since it's their official image.
I think you must have missed that the first post is a replacement of the actual feature request that someone submitted. I have no dog in this fight, but it's pretty slimy to respond to someone's request by overwriting it with your explanation. They effectively hijacked the requester's name, profile picture, and who knows how many upvotes to push their own message instead of letting them have their say and, you know, replying.
Which one, the go ahead and "define your own custom loader"? You mean re-implement the image export that is sitting right there in their express server... from scratch? Hah.
NextJS won't let you export their optimized images in a static site export because they want _everything_ running through their Express server.
Why's that great for them? Because they get to charge you for image bandwidth and image optimization. This is called vendor lock in.
Sources:
In vivo (v13.3.0):
> npx next export
<...>
error - Image Optimization using the default loader is not compatible with export.
Possible solutions:
- Use `next start` to run a server, which includes the Image Optimization API.
- Configure `images.unoptimized = true` in `next.config.js` to disable the Image Optimization API.
Read more: https://nextjs.org/docs/messages/export-image-api
The comparison to npm is worrisome. npm inc. spent years trying to make a profit & grow beyond "privately owned package registry". It failed and was acqui-hired by Github back in 2020 for an amount far beneath its capitalization.
The Image/img fiasco really pulled the covers off for vercel for me. I have migrated all my work off of the platform.
NextJS’ lint strategically dissuades you from using the img tag in favor of the NextJS Image component. If you make the mistake of heeding this advice and migrating to it, you can’t use static site generation—which means you are stuck using their hosting.
Here’s one of the most PR-shameful threads I’ve ever read in OSS:
https://github.com/vercel/next.js/discussions/19065