Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
- 15 commits
- 56 files changed
- 10 contributors
Commits on Jul 2, 2024
-
fix: Backport class properties fix (#67377)
### What? Backport swc-project/swc#8835. Changes: - `swc_core`: `v0.90.30` => `v0.90.31` - `swc_ecma_transforms_compat`: `0.163.18` => `v0.163.19` ### Why? It fixes a bug of class properties transform. ### How? Fixes #66085
Commits on Jul 9, 2024
-
fix(next): initial prefetch cache not set properly with different sea…
…rch params (#65977) cc @icyJoseph @ztanner NOTE: The canary release [`v14.1.1-canary.51`](https://github.com/vercel/next.js/releases/tag/v14.1.1-canary.51) and below work as expected. ### Why? Introduced from #61535, the initial prefetch cache is set based on the `location.pathname`. When a page is loaded WITH the search param, the cache key does not contain information of the search param. The issue is when on a dynamic page reading the `searchParams` value, the value doesn't change if navigated as: ``` /?q=foo --> / ``` The prefetch cache hits, not re-rendering, and the `searchParams` value is not passed properly. ### How? For the prefetch cache, add the `location.search` as well. Since `createPrefetchCacheKey` uses [`createHrefFromUrl`](https://github.com/vercel/next.js/blob/canary/packages/next/src/client/components/router-reducer/create-href-from-url.ts) which includes `location.search`, I'm expecting the change won't affect current cache key behavior. Fixes #64170 Fixes #65030 --------- Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
-
perf: improve retrieving
versionInfoon Turbo HMR (#67309)Identified the bottleneck of Turbopack HMR, one of the reason is that we run `execSync` to get user's package manager and fetch their registry to get the latest & canary version of Next.js. This process was located at the initial of HMR, which could have been delayed to the initial of the error handling. - Remove getting user's package manager and just fetch from NPM regardless the user uses Yarn. - Used an async IIFE to await the promise of `getVerionInfo` value inside the synchronous `ws.handleUpgrade`. > Benchmarked with console inside try-finally | Version | Ready | |-------------------------------------|---------| | Canary | 1185ms | | Delta | 896ms | | Delta Webpack vs Canary Webpack | -24.39% | | Version | Ready | |-------------------------------------|---------| | Canary | 1002ms | | Delta (Turbopack) | 509ms | | Delta Turbopack vs Canary Turbopack | -49.20% | --------- Co-authored-by: Jiachi Liu <inbox@huozhi.im> Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
3 people committedJul 9, 2024 -
-
Fix noindex is missing on static not-found page (#67135)
Render noindex into a flight data and rsc payload when page path is `/404` When it's static generation, noindex is not rendered due to the statusCode from mock request is 200, but we can relying on the pagePath as `/404` page should always contain `nonidex` We were missing the noindex before for flight generation, now we'll render it when it's 404 page.
-
Use addDependency to track metadata route file changes (#66714)
Use `addDependency` to track the file path passed to `next-metadata-route-loader` NOTE: We cannot apply the `next-metadata-route-loader` directly to the metatda convention source files, since the json file could be processed by json loader (Related previous fix #62615) Previously when we passed down the file path as argument to the loader, which sort of breaking the caching of webpack as the actual resource path is string, it's not tracked as a dependency. This change fixed the bad caching issue of static metadata routes. Based on the above reason we use `addDependency` here to track the dependency change Closes NEXT-3521 Closes #65755
-
fix(next-swc): correct path interop to filepath for wasm (#65633)
### What For loading wasm, path interop to absolute file path occurs in here (https://github.com/vercel/next.js/blob/canary/packages/next/src/build/swc/index.ts#L1249) already so shouldn't pre-populate import path when call loading wasm to make internal path operation (https://github.com/vercel/next.js/blob/canary/packages/next/src/build/swc/index.ts#L1247) work.
-
fix(next): reject protocol-relative URLs in image optimization (#65752)
This PR introduces a **breaking change** that returns a 400 error if the Image Optimization API is given a protocol-relative URL. The Image Optimization API currently checks whether the given image URL is relative by checking `url.startsWith('/')`. This means that protocol-relative URLs, such as `//example.com`, pass the check and are treated as relative. They in turn skip any kind of validation provided when matching against `remotePatterns` and are passed back to the optimation logic as a relative URL. My knowledge of the stack stops there, but in our case at GitBook it led to a nasty attack where non-GitBook content could be served over this URL: https://docs.gitbook.com/_next/image?url=//example.com&w=1200&q=100 - even though we have configured `remotePatterns` to protect against it. I originally went into the problem wanting to handle the URL properly (treating it as an absolute URL and potentially using the protocol of the Optimization API itself as the relative protocol), but after seeing the code in https://github.com/vercel/next.js/blob/canary/packages/next/src/client/legacy/image.tsx#L135 and https://github.com/vercel/next.js/blob/canary/packages/next/src/shared/lib/image-loader.ts#L26 it feels that protocol-relative URLs are just not really supported anywhere. My understanding is that very few uses of `next/image` will be allowed to use protocol-relative URLs, so the impact of this breaking change should be quite low? If others disagree I am happy to modify and to use the protocol of the request as a stand-in for the relative protocol. --------- Co-authored-by: Steven <steven@ceriously.com> -
Fix server action edge redirect with middleware rewrite (#67148)
-
avoid merging global css in a way that leaks into other chunk groups (#…
…67373) ### What? This disallows merging of global css with styles that appear on other pages/chunk groups. ### Why? Before we made the assumption that all CSS is written in a way that it only affects the elements it should really affect. In general writing CSS in that way is recommended. In App Router styles are only added and never removed. This means when a user uses client-side navigations to navigate the application, styles from all previous pages are still active on the current page. To avoid visual artefacts one need to write CSS in a way that it only affects certain elements. Usually this can be archived by using class names. CSS Modules even enforce this recommendation. Assuming that all styles are written this way allows to optimize CSS loading as request count can be reduced when (small) styles are merged together. But turns out that some applications are written differently. They use global styles that are not scoped to a class name (e. g. to `body` directly instead) and use them in different sections of the application. They are structured in a way that doesn't allow client-side navigations between these sections. This should be valid too, which makes our assumption not always holding true. This PR changes the algorithm so we only make that assumption for CSS Modules, but not for global CSS. While this affects the ability to optimize, applications usually do not use too much global CSS files, so that can be accepted. fixes #64773
-
Ensure turbo is setup when building in docker (#66804)
This ensures we always set up turbo to the version we expect even if we're building in docker since the cache is pulled outside of docker. x-ref: https://github.com/vercel/next.js/actions/runs/9484631800/job/26134568488
-
Log stdio for pull-turbo-cache script (#66759)
Gives us more context when this fails as it is here https://github.com/vercel/next.js/actions/runs/9469195858/job/26087290365#step:15:23
-
Commits on Jul 10, 2024
Loading
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff v14.2.4...v14.2.5