This pull request correctly tracks render cancelation behavior. Prior to this PR, we'd have an unhandled rejection that left the app in a bad state and no routeChangeError event was fired.
---
Closes#16424Fixes#16445
This makes sure to also check if a dynamic route matched after resolving a rewrite on the client to match behavior on the server. It also adds tests for this behavior to ensure it is working properly.
Fixes: https://github.com/vercel/next.js/issues/16454
This fixes a client-side file not being transpiled correctly when rewrites are used. The cross browser tests have been updated to make sure there are rewrites so the related code is included and not dead-code eliminated'
Closes: https://github.com/vercel/next.js/issues/16440
This corrects the case where `/index` is used during revalidation for an optional catch-all route and `index` is passed as a param even though it should be undefined. This also adds test cases to make sure the params are normalized correctly
Fixes: https://github.com/vercel/next.js/issues/16366
We were accidentally allowing data requests to be rendered unconditionally. Instead, we should also check them against the staticPaths result and 404 when appropriate.
---
Fixes#15383
The comment on the two different `--help` sections matched, though their logic if what was handled was slightly different.
This adjusts the comments to clarify that difference.
This is completely unrelated to function, but I noticed it while reviewing code and thought I'd PR the fix.
This fixes page checking failing due to the trailing slash being present which causes pages to proxied by a rewrite when they shouldn't be. This also adds additional tests to ensure rewriting to an external resource is working correctly with `trailingSlash: true`
Fixes: https://github.com/vercel/next.js/issues/15700
This corrects the basePath being required check for filesystem routes to not consider the public folder catch-all route since it always matches even if the public file isn't present and instead moves the basePath check inside of the public-folder catch-all. Tests already exist that catch this by adding a public folder to the existing `basepath` test suite
Fixes: https://github.com/vercel/next.js/issues/16332
Closes: https://github.com/vercel/next.js/pull/16350
This interpolates the dynamic values and rebuilds the request URL for fallback SSG pages since the proxy uses the output path for non-prerendered pages on Vercel which can cause inconsistent request URL/`asPath` values for SSG pages. This also adds tests to ensure the `asPath` is correctly updated
Fixes: https://github.com/vercel/next.js/issues/16269
Prior to this PR, `loadPage` would call `loadScript` which would then report if the script failed to load.
This was problematic because `loadScript` notified a failure to load via `pageRegisterEvents`, which would not set the `pageCache` value for future requests.
This means a one-off promise rejection would happen, [in lieu of being] typically consumed within the client-side router, causing a server-side reload.
However, when `loadPage` was used independently (i.e. to preload pages), this promise rejection would be ignored as a preload failure.
When the real routing request comes in, the `loadPage` function skips its attempt to load the `<script>` because it was already in the DOM, and the router would stop functioning.
---
To fix this behavior, I've removed erroneous emits on `pageRegisterEvents` to only happen during the page registration lifecycle (its intended use).
The new behavior is that `loadScript` returns a `Promise` that `loadPage` can track, and if any of the page(s) scripts fail to load, we mark the entire page as errored in `pageCache`. This ensures future requests to `loadPage` will always immediately reject with a `PAGE_LOAD_ERROR`, which causes the server-side redirect at the appropriate point.
---
Fixes#16333
This fixes an edge case where every dozen or so transitions you'll see a flash depending on what's happening on the main thread at the time.
I'm not sure it's possible to test for this case, so we'll just have to do more field testing with this.
This PR replaces `prop-types-exact` (only used in this location) with manual property checking.
Right now, malformed properties sent to `<Link>` are silently handled and only emit a warning in the console.
This leads to confusing/unexpected errors because we try to read a value that is undefined.
To fix this, we'll now throw a proper error when `<Link>` is misused. **This still isn't optimal, however, because we don't have a component stack trace we can give the user**.
We're not going to be able to give the user actionable instructions until React 16.14 at a minimum.
---
Fixes#13951Fixes#16107Closes#13962
Don't use this yet as it's still being developed. This is a first iteration that enables the webpack cache. There's still more to do here, for example if css modules are used there's currently a bug where webpack does not save the cache for browser compilation (impacting build performance). @sokra is going to look into that issue.
