forked from vercel/next.js
-
Notifications
You must be signed in to change notification settings - Fork 0
[pull] canary from vercel:canary #50
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
Merged
Merged
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 the development integration test manifest used when testing Turbopack.
This auto-generated PR updates the production integration test manifest used when testing Turbopack.
## What? Fixes the tests in `test/production/app-dir/symbolic-file-links/symbolic-file-links.test.ts`. Found that the test was failing because symlinks were incorrectly copied, they got turned into absolute paths linking to the original repository. Fixed that. Also removed two tests that are the same as checking the html version of the page. As they are effectively duplicated. <!-- 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 # -->
## What? Fixes the test checking deterministic builds. The reason it was failing is that we incorrectly wrote the build manifest directly as middleware build manifest but it needs some adjustments. There's a function for that already, so just using that function matches the behavior we use with webpack. Easy fix. Improved the test to show the file contents whenever the test fails. <!-- 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 # -->
### What? - Added additional debug logging for `customRoutes`, `publicFolderItems`, and `nextStaticFolderItems` in the filesystem router utils - Improved the dynamic route interpolation test to check all script sources instead of just the first matching one - Fixed the Turbopack build test manifest to correctly mark the dynamic route interpolation test as passing - Updated the `to_string()` implementation in `ServerFileSystem` to use a hyphenated format so that it behaves the same between urlencoded and urldecoded. ### Why? This PR improves debugging capabilities for the filesystem router and fixes the dynamic route interpolation test to be more robust by checking all script sources rather than just the first one that matches certain criteria. The test now properly verifies that both encoded and decoded paths work correctly. ### How? - Added debug statements for additional route-related variables - Refactored the test to collect all script sources and verify each one works with both encoded and decoded paths - Updated the Turbopack test manifest to reflect the fixed test - Changed the server filesystem string representation to use hyphens instead of spaces
…#77376) ### What? Changed the PostCSS plugin format in create-next-app templates from string array syntax to object syntax. ### Why? The array string format for PostCSS plugins is non-standard, and gives errors when loading using [postcss-load-config](https://github.com/postcss/postcss-load-config): ``` TypeError: Invalid PostCSS Plugin found at: plugins[0] ``` This change ensures that Next.js applications using Tailwind CSS can seamlessly integrate with these tools without requiring manual configuration fixes. For example, vitest will crash, which uses `postcss-load-config` under the hood: storybookjs/storybook#30878 ### How? Modified the PostCSS configuration in both JavaScript and TypeScript empty app templates with Tailwind to use the object-based plugin format, which is the standard format recognized by PostCSS tools in the ecosystem. Array syntax: ```tsx const config = { plugins: ["@tailwindcss/postcss"], }; export default config; ``` Object syntax ```tsx const config = { plugins: { "@tailwindcss/postcss": {}, }, }; ``` Co-authored-by: Lee Robinson <lee@leerob.com>
## What? Moved the basepath e2e tests into a dedicated directory structure and simplified the test setup: 1. Relocated `basepath-trailing-slash.test.ts` and `basepath.test.ts` into a dedicated `basepath` directory 2. Simplified the test file setup by using `files: __dirname` instead of explicitly referencing individual directories 3. Updated the regex patterns in the prefetch test to be more flexible with optional characters, matching the Turbopack pattern. 4. Updated the test manifest files to reflect the new file paths 5. Fixed a previously failing test: "basePath should prefetch pages correctly in viewport with <Link>"
### What? Disable these test cases until we have a css chunking implementation for pages router too
This auto-generated PR updates the development integration test manifest used when testing alternative bundlers.
This auto-generated PR updates the development integration test manifest used when testing Turbopack.
This auto-generated PR updates the production integration test manifest used when testing alternative bundlers.
…7397) For a tracing GC to work (different for cache eviction), we need `TraceRawVcs` to be able to inspect function arguments. While a tracing GC is still far off, the immediate motivation here is using tracing to improve logging for "transient task called from persistent task" error messages. There's one non-test mpsc queue (`ComputeUpdateStreamSender`) with a sketchy `TraceRawVcs` impl. We should have a way of excluding certain objects from GC (marking them as roots) to fix this in the GC case. IMO this doesn't really matter for non-GC debug use-cases of `TraceRawVcs`.
- fixes [PACK-3337](https://linear.app/vercel/issue/PACK-3337/detect-urlexamplecomblahcss-as-external-in-css-imports) - This fix allows users to put a url like `@import "//example.com/stylesheet.css"` in their css files and be treated as an external url with no specified protocol - Refactors the code for readability by splitting up the different types of patterns into their own respective handler functions - Moved the `lazy_static` section outside of the function definition to slightly increase performance by no longer needing the runtime checks for those elements initialization. - Added a test case to help make sure that the output matches what we expect when encountering protocol-relative urls (e.g. `//example.com/stylesheet.css`)
### What Upgrade the `@vercel/og` patch to Next.js which will resolve the build issue on windows. Closes NEXT-4069 Related #77164 Related: nodejs/nodejs.org#7438
We're currently working through some issues surfaced by the new per-segment routes introduced by the Segment Cache experiment. Testing of this feature in production has been blocked while we figure that out. However, aside from per-segment prefetching, there are a bunch of client-only changes and improvements to the Segment Cache implementation that we can test in the meantime. So, I've added a "client-only" option the `clientSegmentCache` flag. When enabled, Next.js will not generate per-segment prefetch responses, but the client will switch to the new prefetching implementation. This includes: - De-duping of shared layouts across prefetch requests. - More resilience to race conditions. - Prefetch cancellation on Link viewport exit. - Re-prefetching stale data after revalidateTag/revalidatePath. etc. It's essentially a complete rewrite of the client-side prefetching implementation. Given the scope of the change, it may contain subtle regressions that I haven't yet discovered. That's why it's so urgent for me to start testing this in real apps. I initially hesitated to implement the "client-only" option because 1) there are already so many combinations of flags and forked implementations to juggle, and I didn't want to add another one, and 2) I thought it would take less time to fix the deployment issues that are blocking the wider rollout. But it turned out to be less net new complexity than I anticipated, given that I already had to support `ppr: "incremental"`, which works in a largely similar way.
useIsDevRendering is a global pending state for router navigations/ actions. The idiomatic API for this pattern is useOptimistic. Previously, this was implemented using useSyncExternalStore, which led to an additional sync render every time a navigation completed. The advantage of useOptimistic is that it gets automatically reverted in the same commit as the transition it's associated with. <!-- 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:
Adds a field `navigatedAt` to the CacheNode type. It represents the timestamp of the navigation that last updated the CacheNode's data. This will be used to implement the `staleTimes.dynamic` configuration option, which allows dynamic data to be stale in the UI up to the given threshold. This first PR adds the field without changing any behavior. Originally I was going to call this `requestedAt`, but I have intentionally chosen not to distinguish between whether the data was fetched from the network or from the prefetch cache. This means that even fully static data will respect the `staleTimes.dynamic` configuration option. In practice, this only matters if the dynamic stale time is longer than the static one, although usually static stale times will be larger anyway.
Addressing the API incompatibility in the newest Playwright release: microsoft/playwright#27059 (comment) cc @wyozi
… manager (#77633) ### What? - add mention of bun and other package manager in the `ci-build-caching` documentation ### Why? - make the documentation account for other package managers instead of showing any sort of package manager favoritism Fixes #57079 Co-authored-by: Lee Robinson <lee@leerob.com>
### What? Handle duplicates in `nodes_to_merge` by checking the existence of a node using graph. ### Why? Because the previous code fails on one of the internal apps. ### How?
### What? Resolve `ModulePart::ModuleEvaluation` as `ModulePart::InternalEvaluation` while **resolving reference**. ### Why? If we don't do this, the module containing the latest side effect is duplicated. ### How?
### What? Ensuring server-side processing for the loader function of `next/dynamic` with `ssr: false` is properly skipped in Turbopack. ### Why? Previously, client components imported through `next/dynamic` with `ssr: false` were not skipped, while they are skipped in webpack. This fix ensures consistent behavior between Webpack and Turbopack. This is a compilation performance win for applications that leverage this pattern heavily, as it can skip work it doesn't need to process. Was looking at fixing one of the failing tests in the list of remaining tests. Found it checked for this behavior and fixed it. ### How? - Added the same `should_skip_ssr_compile` logic to the Turbopack state that was already implemented for Webpack - When `ssr: false` is specified and we're in the server compiler we replace the dynamic import with an empty async function to avoid bundling the client component on the server
### What? Fix Turbopack test for missing suspense with CSR bailout by conditionally checking for source file path in error output only when not using Turbopack. ### Why? The path in the error output is different when using Turbopack, causing the test to fail. This change makes the test pass in both environments by skipping the path check when Turbopack is enabled. Applying sourcemaps during prerendering is being worked on. We'll be able to un-skip the particular check when it's ready.
…che (#77577) The `revalidateTag` method of the incremental cache should not also handle the revalidation for the `"use cache"` cache handlers. This PR relocates those bits to the revalidation utils module, which was previously used for `after`, and has now been lifted one level up. There should be no behavioral change in this refactoring.
#77595) With the change in #76885, we don't need to update the expiration date of implicit tags anymore at the end of a request to ensure no stale data is used after `revalidatePath` was called in a server action. This PR is covered by the existing tests, e.g. `use-cache should revalidate caches after redirect`.
## Description At #76583, tailwind theme font referenced the [Geist font](https://vercel.com/font). ```css // globals.css @import "tailwindcss"; ~~~ @theme inline { --color-background: var(--background); --color-foreground: var(--foreground); --font-sans: var(--font-geist-sans); --font-mono: var(--font-geist-mono); } ~~~ ``` However, these `font-sans` and `font-mono` variables aren't used now. This PR uses them instead of `font-[family-name:var(--font-geist-sans)]` and `font-[family-name:var(--font-geist-mono)]` for convinience. CC: @samcx Co-authored-by: Sam Ko <sam@vercel.com>
…when reading the output (#77922) ### What? When using mark_finished() on a task, reading that task while it's still in progress will lead to a panic because it would try to schedule that task for recomputation, but it's already scheduled.
sourcecode -> source code sourcemap -> source map
This auto-generated PR updates the production integration test manifest used when testing Turbopack.
This auto-generated PR updates the development integration test manifest used when testing Turbopack.
Also inlined some of the indirections that we no longer need.
<!-- 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: https://linear.app/vercel/issue/DOC-4469/turbopack-for-builds --------- Co-authored-by: Sebastian "Sebbie" Silbermann <sebastian.silbermann@vercel.com>
This is absolutely useless with numerical ids (prod build with `turbopackMinify: false`): ```css /* 51318 */ .base2-module__zzC_ua__base { color: #ff0200; } /* 29244 */ .base2-scss-module-scss-module__JjfRsa__base { color: #ff0300; } /* 85234 */ .base-module__DNnTeq__base { color: red; } /* 29244 */ .base2-scss-module-scss-module__JjfRsa__base { color: #ff0300; } ```
Decoupling from: #73437 - Add "How `use cache` works" section - Clarify cache keys inputs - Describe what happens during build, runtime, and revalidation - Correct the default values for the `cacheLife` profiles - Add the default time for `expireTime` - Add note about `staleTimes` and `expireTime` affecting the default cache profile
Updating the docs after playing around with `useLinkStatus`: vercel/next-app-router-playground#184 Closes: https://linear.app/vercel/issue/DOC-4514/update-docs Main changes: - Update introduction - Simplify example - Add example for gracefully handling fast navigations (avoiding UI flash)
#77994) When rendering the page on Vercel, we send the `x-matched-path` header to indicate which route should be rendered. Sometimes, like in the case of a middleware rewrite, we will rewrite a path to a statically generated one. This results in a `x-matched-path` header being equal to the generated page and not the route with the dynamic path params in it. This ensures that if we get such a path that we match against that we do save the result of the path matching as they are valid parameters. This also fixes a related bug associated with route denormalization which must occur before the routes i18n is parsed. <!-- 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 # --> Fixes #77789 --------- Co-authored-by: Jiwon Choi <devjiwonchoi@gmail.com>
### What? Quick debug check to panic for duplicate modules
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )