The next-metadata-route-loader emitted content with `"next/server"` is still using cjs version which is not get tree-shaked on edge runtime, This PR adds a new esm entry for it and mapped it that on edge runtime so unused exports can be tree-shaked. This case happened when users are using ImageResponse from `"@vercel/og"` instead of `"next/server"`.
2nd change is adding another alias to map `@vercel/og` package to vendored og package inside next.js, this way we could merge the two package instead of bundled both of them
Fixes: NEXT-1303
changed `require.reoslve("next/dist/xxx")` to `${NEXT_PROJECT_ROOT}/xxx}` to avoid to be traced by nft.
Follow up of #48867
- Statically optimize dynamic generated sitemap routes
- Previously the generated sitemap urls looks bit off
(`/route/sitemap.xml/[id]`), we polish it into `/route/sitemap/[id].xml`
in this PR
* Fix the `generateImageMetadata` for non dynamic routes and related
`param` matching (Found during development)
* Fix dynamic routes with number suffix `(\d)` (Fixes#48689)
### What
For dynamic routes you might have different sitemap for different params
* Unloack using `sitemap.[ext]` in your app everywhere
* Support `generateSitemaps()` to create multiple sitemaps at the same time
### How
* Change the metadata regex to allow use sitemap in every routes
* Similar approach to `generateImageMetadata`, we make `sitemap.js` under dynamic routes to a catch all routes, and it can have multiple routes
Closes NEXT-1054
Use should only need to configure one `metadataBase` as fixed domain or
url but metadata image routes can still work properly with `VERCEL_URL`
in preview deployments
If you configured `new URL('https://mydomain.com')`, it will work for
canonical url all the time since it's for SEO.
For preview deployments metadata image routes will work with deployment
url as they're always bound with deployment.
For production deployments metadata images routes can be alias to the
configured `metadataBase` as they could be the expected exposed domain
Follow up for #47910
link NEXT-887
### What?
* Support `generateMetadata(props)` to dynamically generate multiple
metadata images at the same time
```js
// /app/opengraph-image.tsx
import { ImageResponse } from 'next/server';
export async function generateImageMetadata({params}) {
const images = await ...;
return images.map((img, idx) => ({
size: { width: 1200, height: 600 },
alt: img.text,
contentType: 'image/png',
id: idx,
}));
}
export default async function ({params, id}) {
const text = await getTextFor(id);
return new ImageResponse(
(
<div
style={{...}}>
{text}
</div>),
{ width: 1200, height: 600 },
);
}
```
### How?
Use `<metadata image>/[[...__metadata_id__]]/route.js` to catch all
metadata images id, and then use this `params.__metadata_id__` as id
argument for dynamic generate image.
If there's param, then we create `<metadata image>/<id>`, if there's
only 1 static image without dynamic `generateImageMetadata` then we keep
use `<metadata image>`
Closes NEXT-896
### What?
The change in #47985 breaks the URLs of static image files like
`/(group)/opengraph-image.png` to `/opengraph-image.png-012345`.
References from `/` are also broken.
### Why?
This is because only `opengraph-image.ts` and `opengraph-image.tsx` are
considered.
### How?
In this Pull Request, we are trying to solve the problem by including
similar support for `opengraph-image.png` and `opengraph-image.jpeg`.
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
### What
When using dynamic metadata image rouets (such as `opengraph-image.js`)
under group routes, the generated urls were still normalized. In this
case it might have conflicts with those ones not under group routes. For
instance `app/(post)/opengraph-image.js` could have same url with
`/app/opengraph-image.js`. In reality we want them to be different
route, unlike layout or pages.
### How
So when we found `()` or `@` signs from the metadata image urls, we'll
generate a unqiue suffix (`-\d{6}`) and append to the generated url. So
they can be isolated from the ones are not under special convention
routes.
Closes NEXT-937
Should fill dynamic routes url with params when generate the metadata
image urls.
For `/(group)`, we need to normalize the path first;
For dynamic routes `/[slug]`, we need to fill the params.
Change the image module from `() => image` to `(prop) => image(proop)`
so we can fill the runtime `params` into url
Closes NEXT-932
---------
For backward compatibility, we only handle `favicon.ico` file to
generate `/favicon.ico` route and link tag. If you want to use other
extension such as `png`, use `icon(\d)?.[ext]`
### What?
- Provide a default `metadataBase`
- Always resolve urls that could be resolved as absolute with
`metadataBase`, e.g. tw/og urls, canonical urls
- Give a warning in dev mode if user doesn't provide one in dev
- Error if you don't have it but it's required in production
On production it will leverage `VERCEL_URL` if users expose it to the
deployment
### Why?
OG image urls are required to be absolute urls instead of relative urls.
For metadata image conventions we let users don't have to provide
`metadataBase` explicitly when they expect it should be the origin of
their next app.
### How?
Closes NEXT-887
---------
### What?
Followup for #47630 , use ts namespace to group MetadataRoute.
`MetadataRoute['xxx']` -> `MetadataRoute.xxx`
### Why?
namespace is convenient to write for these grouped types such as
`MetadataRoute.Robots`. And `MetadataRoute` itself is not actually a
type. So it can be conveniently typed by ts users.
### How?
Closes NEXT-912
---------
### What?
This PR vendors @vercel/og and export `ImageResponse` from
`next/server`. When you render a opengraph image the below code snippets
will be legit:
```tsx
import { ImageResponse } from 'next/server'
export default function og() {
return new ImageResponse(<div style={{ width: '100%', height: '100%' }}>hello</div>)
}
```
### Why?
To make development more easier, user can directly use `@vercel/og`
Image Response with nextjs instead of install it and use it. This makes
building metadata icons, og or twitter images more convenient.
### How?
Closes NEXT-899
### What?
- Besides existing `Metadata` type, expose `ResolvingMetadata` and `ResolvedMetadata` to `'next'`.
- Group `Robots` / `Sitemap` / `Manifest` these dynamic data routes types as `MetadataRoute` type and expose to `'next'`
### Why?
Allow users to type the more API easily, and grouping them to avoid type conflicts (e.g. we have `Robots` in metadata interface field, `MetadataRoute.Robots` can avoid conflicts)
### How?
Closes NEXT-908
Reverts vercel/next.js#47372
```
Error occurred prerendering page "/apple-icon". Read more: https://nextjs.org/docs/messages/prerender-error
Error: The `ImageResponse` API is not supported in this runtime, use the `unstable_createNodejsStream` API instead or switch to the Vercel Edge Runtime.
at new ImageResponse (/tmp/next-install-db63e2a2f25e9feda48affa69456fcbdde8d89bf94645e42abd2aa522224f432/.next/server/chunks/558.js:26416:19)
at appleIcon (/tmp/next-install-db63e2a2f25e9feda48affa69456fcbdde8d89bf94645e42abd2aa522224f432/.next/server/app/apple-icon/route.js:127:12)
```
https://github.com/vercel/next.js/actions/runs/4490842502/jobs/7899302486#step:6:305
Allow image responses returning from dynamic image routes for og/twitter
images, and icon/apple-icon images. This PR supports the basic
functionalities for nodejs runtime of image routes. `@vercel/og` is able
to be leveraged for generating dynamic image responses.
Close NEXT-264
Close NEXT-266
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
* Add `manifest.webmanifest` and `manifest.(j|t)xs?` support for
manifest.json route
* Add `Manifest` type for it for autocomplete purpose.
Remove the exports for `SitemapFile` and `RobotsFile` globally, will
discuss how to re-export them with better naming later
Small fix for `Robots` typing, should allow `string | string[]` for user
agent of single Robots
Closes NEXT-839
---------
Support top-level `robots.[ext]` and `sitemap.[ext]` with dynamic api
routes
* Use isAppRoute to determine api routes and metadata routes as metadata
routes are normalized as `<metadata>/route`
* Normalize path to auto append extension to pathname for sitemap.js and
robots.js
* Add typings `SitemapFile` and `RobotsFile`
* move the normalize logic together, reuse the `absolutePathToPage`.
Changes less when touching both dev-server/hot-reloader and next-server,
use the same utils to handle paths
Closes NEXT-262
---------
