next.js

ea16dfb0 - fix(create-next-app): pin both axes on Tailwind template logos to silence aspect-ratio warning (#95609)

fix(create-next-app): pin both axes on Tailwind template logos to silence aspect-ratio warning (#95609) ## Summary The default `create-next-app` Tailwind templates (`app-tw` and `default-tw`) intermittently log the `next/image` warning "Image with src … has either width or height modified, but not the other" for the `next.svg` and `vercel.svg` logos. Tailwind v4 Preflight ships `img { height: auto }`, which overrides the `height` attribute `next/image` writes. The browser then computes height from `width × the SVG viewBox ratio`. The declared dimensions do not match the viewBox ratio (`vercel.svg`: `16×14` vs viewBox `1155:1000`; `next.svg`: `100×20` vs viewBox `394:80`), so the computed height is fractional (`13.85px`, `20.30px`) and snaps to a different integer depending on SVG decode timing, Fast Refresh reloads, and device pixel ratio / zoom. That timing/rounding sensitivity is why the warning appears only sometimes. This pins both axes with utility classes (`h-5 w-[100px]` on `next.svg`, `h-[14px] w-4` on `vercel.svg`) so neither dimension falls back to `auto`. The rendered size always matches the declared props, so the check cannot trip, at any DPR. Only the Tailwind templates are affected; the non-Tailwind `app`/`default` templates have no `img { height: auto }` reset and do not produce this warning. This extends the both-axes approach from #95252 to `default-tw` as well. #93826 adjusted the dimensions but the mismatch remained (`13.85 ≠ 14`). ## Verification - `prettier --check` on the four changed files passed. - Not run: `create-next-app-default` regression test. It runs headless at DPR 1, where the fractional-pixel rounding does not occur, so it passed even while the warning was present and is not a reliable oracle here. Reproduced/validated by reasoning about Preflight specificity and the removed computed axis. <!-- NEXT_JS_LLM_PR -->