forked from vercel/next.js
-
Notifications
You must be signed in to change notification settings - Fork 0
[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
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
Closes PACK-2940
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).
…ercel#74500) Backports PR vercel#74257 to 14.x
… (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`.
…el#75561) (vercel#75870) Backports: - vercel#75561 - vercel#73482 --------- Co-authored-by: JJ Kasper <[email protected]>
Backports vercel#77201 to v14 release branch
…th middleware (vercel#77794) Backports: - vercel#64923
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
This backports vercel#79386 to 14 release channel
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backports:
🔄 This is a mirror of upstream PR #82179