Skip to content

[backport v14]: fix(next/image): improve and simplify detect-content-type (#82118) #41

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 263 commits into from

Conversation

austinderek
Copy link
Owner

vercel-release-bot and others added 30 commits April 17, 2024 11:56
This auto-generated PR updates font data with latest available

Co-authored-by: JJ Kasper <[email protected]>
## What?

- Removes the node-file-trace options from being unsupported as they are
passed to node-file-trace in build/index.ts
- Ensures `import next from 'next'` is handled in the same way as
webpack: creating an empty module. Currently it tried to bundle all
Next.js internals which is wrong.

<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:

## For Contributors

### Improving Documentation

- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide

### Adding or Updating Examples

- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md

### Fixing a bug

- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md

### Adding a feature

- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md


## For Maintainers

- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change

### What?

### Why?

### How?

Closes NEXT-
Fixes #

-->


Closes NEXT-3086
Super small PR - "oustide" should be "outside"

<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:

## For Contributors

### Improving Documentation

- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide

### Adding or Updating Examples

- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md

### Fixing a bug

- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md

### Adding a feature

- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md


## For Maintainers

- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change

### What?

### Why?

### How?

Closes NEXT-
Fixes #

-->
This ensures we properly skip calling a fetch during build-time that has
`cache: 'no-store'` as it should only be called during runtime instead.

Fixes: vercel#64462

Closes NEXT-3114
…n `type` is set (vercel#63620)

### What?

The string value of `Metadata.openGraph.emails` throws error:

```tsx
export const metadata = {
  openGraph: {
    type: 'article',
    emails: '[email protected]',
  },
};
```

Error:

```sh
r.map is not a function
```

The type is:

```tsx
type OpenGraphMetadata = {
  // ...
  emails?: string | Array<string>
}
```

### Why?

Basic values such as `emails` and `phoneNumbers` were not included when
`ogType` was set while resolving the values.

### How?

Include basic values when resolving the metadata.

Fixes vercel#63415
### What?

The production chunking plugin shouldn't be enabled in development

### Why?

It doesn't handle HMR yet


Closes PACK-2956
## What

Determine if the client module is a CJS file and `default` export is
imported, then we include the whole module instead of using webpack
magic comments to only extract `default` export.

## Why

Unlike ESM, The `default` export of CJS module is not just `.default`
property, we need to include `__esModule` mark along with `default`
export to make it function properly with React client module proxy


Fixes vercel#64518
Closes NEXT-3119
When an action is marked as "discarded", we enqueue a refresh, since the
navigation event will be invoked immediately without waiting for the
action to finish. We refresh because it's possible that the discarded
action triggered some sort of mutation/revalidation, and we want the
router to still be able to respond to that new data.

However there's a bug in this logic -- it'll only enqueue the refresh
action if there were no other actions in the queue, ignoring the case
where something is still in the queue. This makes sure that the refresh
is handled after `runRemainingActions` finishes.

When adding a test for the server component case (which doesn't hit this
refresh branch), I noticed `LayoutRouter` caused React to suspend
indefinitely, because it got stuck in the `use(unresolvedThenable)`
case. We should only suspend indefinitely if we kicked off a the
`SERVER_PATCH` action, as otherwise it's possible nothing will ever
break out of that branch.

Fixes vercel#64517
Closes NEXT-3124
When middleware.js is present, the logging is duplicated. We should
filter out the 1st middleware request and only log the actual one going
through request handler / renderer

Closes NEXT-3125
…el#64520)

Resolves vercel#64412

This adds a client transition to the app route `ModuleAssetContext` and
the corresponding transforms so that client components can be safely
imported and referenced (as their proxies) in app routes.

Test Plan: Added an integration test


Closes PACK-2964
For app page rendering on edge, the `AsyncLocalStorage` (ALS) should be
bundled as same instance across layers. We're accessing the ALS in
`next/dynamic` modules during SSR for preloading CSS chunks. There's a
bug that we can't get the ALS store during SSR in edge, I digged into it
and found the root cause is:

We have both import paths:
`module (rsc layer) -> request ALS (shared layer)`
`module (ssr layer) -> request ALS (shared layer)`

We expect the ALS to be the same module since we're using the same layer
but found that they're treated as different modules due to applying
another loader transform on ssr layer. They're resulted in the same
`shared` layer, but with different resource queries. This PR excluded
that transform so now they're identical across layers.

For webpack, we aligned the loaders applying to the async local storage,
so that they're resolved as the same module now.

For turbopack, we leverage module transition, sort of creating a new
`app-shared` layer for these modules, and apply the transition to all
async local storage instances therefore the instances of them are only
bundled once.
To make the turbopack chanegs work, we change how the async local
storage modules defined, separate the instance into a single file and
mark it as "next-shared" layer with import:

```
any module -> async local storage --- use transition, specify "next-shared" layer ---> async local storage instance
```

Closes NEXT-3085
This adds a normalizer to handle `.action` invokes (when in minimal
mode). This PR by itself does not do anything of note, but will be
hooked up in a future PR in the [Next.js
builder](https://github.com/vercel/vercel/tree/main/packages/next).

<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:

## For Contributors

### Improving Documentation

- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide

### Adding or Updating Examples

- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md

### Fixing a bug

- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md

### Adding a feature

- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md


## For Maintainers

- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change

### What?

### Why?

### How?

Closes NEXT-
Fixes #

-->


Closes NEXT-3131
`initialCanonicalUrl` differs from the `canonicalUrl` that gets set on
the client, such as when there's a basePath set.

This hoists the `canonicalUrl` construction up so we can re-use it when
adding refetch markers to the tree.

This also renames `pathname` -> `path` since it also includes search
params. I added a test to confirm no extra erroneous fetches happened in
both cases.

Fixes vercel#64584


Closes NEXT-3130
…ution on Windows (vercel#64677)

Not 100% sure I did this process right for a hotfix, but this new tag
should be exactly the same as what's currently in the 14-2-1 branch,
except with this one PR:

* vercel/turborepo#7995 <!-- Benjamin Woodruff -
fix(turbopack-node) postcss.config.js path resolution on Windows -->

---

In turbo, I ran

```
git switch --detach turbopack-240411.3
git switch -c bgw/hotfix-turbopack-14-2-1
git cherry-pick e7a5c60a3b899d0c4293589c2844016da82442f7
git push origin HEAD
```

I then ran the GitHub action for the nightly release process for that
new branch:
https://github.com/vercel/turbo/actions/workflows/turbopack-nightly-release.yml
(it seems like this just cuts a tag, I wonder for hotfixes if we should
manually cut the tag so it's named differently)

In the nextpack repository:

```
pnpm next-link turbopack-240417.2
```
### Why

If you have a client entry that mixing `default` re-export and `*`
re-export, atm we cannot statically analyze all the exports from this
the boundary, unless we can apply barrel file optimization for every
import which could slow down speed.

```js
// index.js
'use client'
export * from './client'
export { default } from './client'
```

Before that happen we high recommend you don't mixing that and try to
add the client directive to the leaf level client module. We're not able
to determine what the identifiers are imported from the wildcard import
path. This would work if we resolved the actual file but currently we
can't.

### What

When we found the mixing client entry module like that, we treat it as a
CJS client module and include all the bundle in client like before what
we have the client components import optimization.

Ideally we could warn users don't apply the client directive to these
kinda of barrel file, and only apply them to where we needed.


Fixes vercel#64518 
Closes NEXT-3119
…el#64809)

### What

Reported by @MaxLeiter, when you mixing named import and wildcard import
to a client component, and if you clone the module it will missed others
exports except the named ones. This lead to an issue that rendered React
element type is `undefined`.

### Why

We're using a tree-shaking strategy that collects the imported
identifiers from client components on server components side. But in our
code `connection.dependency.ids` can be undefined when you're using
`import *`. So for that case we include all the exports.

In the flight client entry plugin, if we found there's named imports
that collected later, and the module is already being marked as
namespace import `*`, we merge the ids into "*", so the whole module and
all exports are respected.

Now there're few possible cases for a client component import:

During webpack build, in the outout going connections, there're
connection with empty imported ids (`[]`), cannot unable to detect the
imported ids (`['*']`) and detected named imported ids (`['a', 'b',
..]`). First two represnt to include the whole module and all exports,
but we might collect the named imports could come later than the whole
module. So if we found the existing collection already has `['*']` then
we keep using that regardless the collected named imports. This can
avoid the collected named imports cover "exports all" case, where we
will expose less exports for that collection module lead to the
undefined component error.

Closes NEXT-3177
…l#64894)

### What

* Remove the change added in vercel#64467, but still kept tests.
* Add more tests for mixed imports (component and function) from shared
component with `optimizePackageImports`

### Why

The fix in vercel#64467 was not correct, as mixing `export *` with `"use
client"` should error if Next.js detect it properly.
When there's mixed exports, that a shared function will become a client
reference if the target file inherits the client boundary.

The original issue vercel#64467 fixed was actually related to tree-shaking,
which is fixed in vercel#64681.

Closes NEXT-3197
### What

Apply the react aliases for app dir also to the files with
`pagesExtension`

### Why

In the page bundle of mdx page:

In RSC layer react is referencing to the insatlled react 18.2.0 's
`jsx-runtime` to create each JSX element. The react 18.2 JSX runtime
access `propTypes` of the component type and then it crashes 💥
In RSC layer it should use the built-in react canary's `jsx-runtime`.

The reason that it didn't use the built-in one is we're using customized
`pageExtension` `["mdx"]` for mdx, where we didn't apply all these rules
for the files with `pageExtension`, but only the js and ts files by
default.

For mdx specifically, we cannot only applied to
`(page|layout|route).[page extension]` cause every mdx file needs to
have proper resolution. Since this doesn't break transform, it's safe to
apply for all files with page extension.

Fixes vercel#58888 

Closes NEXT-3187
…rcel#64799)

This PR fixes the fetch cache, which currently is not using the fetch
cache when it exists (the tags were not getting set properly), and tags
have not updated.

(Before)

https://github.com/vercel/next.js/assets/28912696/74d8f592-0698-4ae4-be4b-30cffb1ffe11

(After)

https://github.com/vercel/next.js/assets/28912696/af12b13a-46c6-41c3-9ac3-20e1ec44a865

- vercel#64786
- vercel#63547

Closes NEXT-3173
When the router cache can't find a cache node for the requested segment,
it performs a request to the server to get the missing data. This
request to the server currently will always include the `next-url`
header, and on soft-navigations, the router will route the request to
the intercepted handler. This lazy fetch is treated as a soft navigation
by the server, and will incorrectly return data for the intercepted
route.

Similar to the handling in `router.refresh`, and the server action
reducer, we should not include the `next-url` header if there's no
interception route currently in the tree, as otherwise we'll be
erroneously triggering the intercepted route.

Fixes vercel#64676
Closes NEXT-3146
…l#64730)

When a server action triggers a redirect, we're incorrectly applying a
refresh marker to the segment they were on, rather than the segment they
were being redirected to. As a result, when revalidation occurs (via
`revalidateX` or `router.refresh()`), the top-level segment would be
replaced with data for an incorrect segment.

For example, if triggering a redirect action from `/redirect` to `/`,
the router state tree would save a reference to `/redirect`. The next
time a refresh or revalidate happens, it'd refresh the segment data for
`/redirect` instead of `/`.

Fixes vercel#64728


Closes NEXT-3156
…rom original object (vercel#64727)

### What?

I submitted PR vercel#64499 , it got merged, but it contains a mistake.
I'm terribly sorry about this!

By removing the traceparent from the cachekey, we mistakenly removed the
header from the original object.
Causing the actual request to be executed without the traceparent
header.

### Why?

Creating a cachekey should not alter the original object.

### How?

Flip the arguments for Object.assign

---------

Co-authored-by: Jeffrey <[email protected]>
Co-authored-by: JJ Kasper <[email protected]>
This ensures we only track fetch metrics in development mode as that's
the only time we report them currently, this also adds an upper limit on
how many metrics we store per-request as previously this was unbounded,
on top of that this ensures we don't keep tracking fetch metrics after
the request has ended as we only report on request end, and finally this
adds a clean-up to the reference we attach to the request object
containing the fetch metrics once we have used them.

Closes: vercel#64212

Closes NEXT-3159
In vercel#60645, dynamic access tracking was refactored but we erroneously
stopped tracking dynamic access in route handlers. Request proxying, as
well as tracking segment level configs (such as `export const dynamic =
'force-dynamic'`), were only enabled during static generation. This was
an unintended breaking change that consequently caused dynamic access to
not properly bail from data cache in various circumstances.

This adds some more rigorous testing for route handlers, as this seems
to be a fairly large gap in our fetch cache testing currently.

This PR is easiest to review with [whitespace
disabled](https://github.com/vercel/next.js/pull/66446/files?w=1).
vercel-release-bot and others added 28 commits December 26, 2024 17:15
… (vercel#74573)

This backports vercel#74164 to leverage
built-in waitUntil if available instead of using the approach that keeps
the stream open until the waitUntil promise resolves.

x-ref: [slack
thread](https://vercel.slack.com/archives/C02K2HCH5V4/p1736211642221149?thread_ts=1734707275.666089&cid=C02K2HCH5V4)
…vercel#74590)

Fixes vercel#74062 (`jotai` ran into this error [when they added `"type":
"commonjs"` to their

package.json](pmndrs/jotai#2579 (reply in thread)))

> this is a bug in the transform we do when a `'use client'` directive
is encountered. I think what's happening is that we're creating a
virtual file that uses ESM import/export syntax, but it's called
proxy.js (not proxy.mjs), so the `"type": "commonjs" `makes turbopack
"correctly" upset at the ESM syntax.
vercel#74062 (comment)

The (slightly kludgy) solution is to use `proxy.mjs` or `proxy.cjs` to
force the module format, bypassing the issue where `proxy.js` changes
meaning depending on `package.json#type`.
The previous [backport](vercel#77794)
caused an issue due to how imports are resolved on canary vs v14,
resulting in a message about using node.js APIs in middleware.

This moves the import to the `web` directory and adds a test case for
the warning.

Closes NDX-1014
Add support for detecting more src image formats via magic number. The
src image formats are handled as follows:

- `image/jxl` - serve as is (since safari can render it)
- `image/heic` - serve as is (since safari can render it)
- `image/jp2` - serve as is (since safari can render it)
- `application/pdf` - error (since no browser will render it)
- `image/pic` - error (since no browser will render it)

We also fallback to `sharp().metadata()` if we can't detect the magic
number to ensure correctness.
@austinderek austinderek deleted the ztanner/backport-82118 branch July 30, 2025 22:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.