This handles the case where a middleware rewrite causes us to fail to
resolve the correct dynamic route params for an action sent to a
prerendered ISR path since the matched path wouldn't be the original
source path like we expect and instead is the prerendered path so we
need to parse the params out instead.
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
### What?
Sometimes, probably when you have a lot of tests, I've noticed that some
tests are failing with the error `browserContext.route: Test ended`.
After some debugging I found that `page.route(…)` needs to be awaited
before continuing.
### Why?
So that Playwright works correctly with the `next` fixture.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
- remove fail fast so we can get a full picture of what's failing
- remove alerting/retrying to existing job
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Users that experiment with PPR and might have seen #61798, or #62703, or
most recently #65483, may try the `__nextppronly=1` query param to debug
the static shell. This will lead to the following uncaught error and
blank page:
<img width="1045" alt="static shell debugging hydration error"
src="https://github.com/vercel/next.js/assets/761683/ed382d97-82ae-4a23-9930-bb4d4419e88e">
It might not be immediately obvious that javascript must be disabled to
see the static shell. To improve the DX in this scenario we can omit the
bootstrap script to skip hydration, and thus prevent the error. Then
debugging the static shell works even without disabling javascript in
the devtools.
<img width="1045" alt="static shell debugging without hydration"
src="https://github.com/vercel/next.js/assets/761683/57f6cb88-f5b4-473f-963f-7fda8c8e7f00">
In addition, we should add the closing body and html tags to the shell
so that a valid HTML document is returned.
`node_modules` gets ignored when deployed unless explicitly allowed, and
the regular install command will clobber what was in there.
This allowlists the `node_modules` directory and copies it into a new
folder, runs the install command, and then merges the patched
`node_modules` in so the patched modules are available in the test.
Only 1 test suite in this suite is failing and it's related to file
tracing, which should be fixed in a follow-up. For now this enables
deploy tests for everything else to make sure we don't regress.
This also simplifies the original test to not require stopping the
server & patching a file.
- Fixed redirects tests not working when deployed because they were
`POST` requests to a static page
- Skipped 404 test for a similar reason: a `POST` to the static not
found page is handled differently, and we won't have access to the
runtime logs anyway
- Refactored interception routes test to not rely on runtime logs
- Fixed revalidation test & removed comment about flakiness
<details>
<summary>Validated Run Summary</summary>
![CleanShot 2024-06-13 at 13 45
32@2x](https://github.com/vercel/next.js/assets/1939140/8b85cb60-b389-451c-b449-41067f86a8d3)
</details>
These 2 tests use an in-memory data store that won't be necessarily
shared across invocations of the lambda. This skips the tests that rely
on that functionality as testing it in `next start` should be
sufficient.
I missed that this was used by the comment webhook when I removed it in
#66721. This restores the existing code and adds a better comment
explaining why it's there.
This test was only failing because `vercel logs` limit the output to 100
lines, and telemetry debugging was adding a lot of verbosity to the
build logs.
This bumps the log lines to a higher value to give some more breathing
room, and did a drive-by `check` -> `retry` refactor.
https://github.com/vercel/turbo/pull/8165 introduced plugins that
operate before resolving occurs, meaning that plugins like
`InvalidImportResolvePlugin` which never use the initial resolve result
and report issues can avoid that work.
Test Plan: `TURBOPACK_DEV=1 TURBOPACK=1 pnpm test-dev
test/development/acceptance-app/invalid-imports.test.ts`
Upgrade devdependecy commander to latest versio.
Now in command, the optional argument is with [] and the required
argument is with <>.
---------
Co-authored-by: torresgol10.itd <torresgol10.itd@gmail.com>
Co-authored-by: Sam Ko <sam@vercel.com>
This disables tests that should not be run in a deployed environment,
because they use incompatible APIs or there's no reason to test them
outside of `next start`. Specifically disables for things like:
- Using `next.patchFile`, `next.renameFile`, etc.
- Attempting to use `next.cliOutput` to query runtime logs. When
deployed, these are only build-time logs.
[Latest Run](https://github.com/vercel/next.js/actions/runs/9483807368)
- `next.cliOutput` will only refer to build time logs, so this
particular assertion won't work
- Drive-by refactor for it to use `retry` instead of `check`
Verified this passes when deployed
[Test
Run](https://github.com/vercel/next.js/actions/runs/9471783416/job/26095882422)
Changes:
- Add a setup step that clears the project so it doesn't happen in each
runner
- Run when a release is published rather than on cron
- Notify via Slack when a failure occurs
- Leverage build_reusable for the test runner to match the
build_and_test workflow
- Fixes to `next-deploy` script: not properly logging/catching errors
- Adds manifest to ignore known issues
- Split into 6 runners with 2 concurrency (12 deploys at a time)
- Adds some logging so we know what's happening
- Disable Playwright trace mode (it kept failing to find a trace file
and cluttering the output. Don't think we need it here anyway)
<details>
- <summary>Removed noisy output</summary>
![CleanShot 2024-06-10 at 14 08
05@2x](https://github.com/vercel/next.js/assets/1939140/f227e71c-95b4-4859-90de-a23c88c55ea8)
</details>
<!-- 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 #
-->