### 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>
</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>
</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 #
-->
### What?
This modifies the static generation store to instead store a `url`
object with the `pathname` and `search` properties. This corrects the
previous behaviour which used the variable `urlPathname` which had
ambiguous meanings as it technically contained the search string as
well, not just the pathname.
In cases during the app render, this still grabs the contents of
`url.pathname + url.search` (where `url.search` always has a leading `?`
if it has any query parameters, [see the
docs](https://developer.mozilla.org/en-US/docs/Web/API/URL/search)) so
that it emulates the current behaviour. This allows more specific access
though, where now additional parsing can be eliminated which had to
strip the query string off of the `urlPathname` in a few places, and
more worrisome, still accidentally contained the search string causing
errors.
### How?
This requires an upstream fix (#64088) which corrected a bug with the
store access which had caused some previous test failures (accessing
`store.url.pathname` was throwing as `store.url` was undefined on the
wrong return, check the upstream PR for more details on that).
This also changes out usage of `pagePath` with `route`, and lets it be
the fallback (for debugging and error messaging). During static
generation, we will provide a value for the page being rendered that's
correlated to the particular file on the filesystem that the route is
based on:
```
// rendering app/users/[userID]/page.tsx
page: /users/[userID]
pathname: /users/1, /users/2, etc
```
The `route` is used only for debugging, such as when
`generateStaticParams` incorrectly calls `headers()`.
This also moves the pathname from the `staticGenerationStore` into the
`requestStore`, as it's tied to a given request.
Closes NEXT-2965
Closes [#66650](https://github.com/vercel/next.js/issues/66650)
Closes NEXT-3520
### What?
- Make Link not throw during prefetch if it received an invalid `href`
(see [#66650](https://github.com/vercel/next.js/issues/66650))
- Throw in dev mode if an invalid link was passed to `router.prefetch`
-- this matches current prod behavior
- (previously, we'd immediately exit out of `router.prefetch`, so the
user would see no indication that this'd fail in prod)
### Why?
If an invalid URL was passed to `<Link>`, the whole app would crash and
show "A client-side exception occurred". A failed prefetch should not
bring down the whole app.
Note that This preserves the current behavior of explicit
`router.prefetch(url)` throwing an error if `url` is invalid. We may
want to adjust this in the future, but that could be considered a
breaking change, so I'm leaving it out for now. This only affects
`Link`, which was intended to catch any errors thrown from
`router.prefetch`, but that bit was accidentally broken.
