## What?
Follow-up to #63665.
Ensures development tests are skipped during the production build run
for Turbopack (i.e. used to create the turbopack-build-tests-manifest).
Adds `pnpm test-dev-turbo` and `pnpm test-start-turbo` (and their
`testonly` equivalent) for running tests.
<!-- 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-2915
- Enable newNextLinkBehavior. See #36436
- Run next/link codemod on test suite
Note that from when this lands on apps trying canary will need to run
the new-link codemod in order to upgrade.
Ideally we have to detect `<a>` while rendering the new link and warn
for it.
Co-authored-by: Steven <steven@ceriously.com>
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
Update tests to setup webdriver stuff in `jest-environment` and re-use one browser session instead of spawning one for each webdriver call to prevent creating too many BrowserStack sessions.
* Set default `Error` status code to 404
This is an appropriate default behavior because:
1. When the server encounters an error, the `err` property is set.
2. When the client-side application crashes, the `err` property is set.
This means the "only" way to render the `/_error` page without an error
is when a page is not found (special condition).
Fixes#6243Closes#5437
* Add new integration test for client side 404
* single quotes
* Remove unused variable
* Standard needs to go away
* Whoops
* Check for null status code in res and err
* Only check response for valid statusCode
