May have been a leftover from earlier.
We always consider any throw. Even without a sync stack, we might still have an async stack to show. And even if we have no stack at all, the message is still relevant. Basically, never hide errors.
This updates the dynamic validation implementation to more closely
follow the pattern used in prerenders for dynamicIO + PPR. Now that PPR
is the only way to use dynamicIO we only have one implementation and the
validation should match it as much as possible.
Continuation of https://github.com/vercel/next.js/pull/78166 this
implements the `handler` interface for pages routes, This does not move
the response handling inside of the handler yet as that will be in a
follow-up PR to keep the changes isolated. This still returns the
`RenderResult` for the `base-server` to continue to handle.
Validated against `vercel/vercel` deploy tests here
https://github.com/vercel/vercel/pull/13349
Best to be reviewed with "Hide whitespace".
### Why?
The props marked `(): any` bypassed the warning for non-serializable
props.
```tsx
'use client'
export function Comp({ onClick }: { onClick(): any }) {
// ...
}
```
Added tests to prevent regression.
---------
Co-authored-by: Janka Uryga <lolzatu2@gmail.com>
Follow-up to #79254, there's one more test flaking with the same issue.
I pulled the label-ignoring logic out into
```ts
expect(browser).toDisplayRedbox('...', { label: false })
```
so that it's easy to find these later when we fix the underlying issue.
To prepare for an upcoming change where `ppr` will be enabled
automatically when `dynamicIO` is enabled, we're hard coding `ppr: true`
in the Dynamic IO tests with this PR. The non-PPR assertions are
subsequently removed, which makes up most of the changed lines.
We can now also exclude the tests in the PPR tests manifest, so that
they're not run twice in CI.
> [!NOTE]
> This PR is best reviewed with hidden whitespace changes.
_Relanding #79151, now ignoring TS AST nodes when checking whether all
exported module items are async functions._
This fixes an error where we incorrectly showed the following compiler
error when using Turbopack:
```sh
Ecmascript file had an error
> 1 | 'use cache'
| ^^^^^^^^^^^
2 |
3 | import { useStuff } from './client-module'
4 |
The "use cache" directive must be at the top of the file.
```
The directive was regarded as not being at the top of the file, because
the React transform (`EcmascriptInputTransform::React`) injects a
variable declaration for React Refresh (e.g. `var _s =
__turbopack_context__.k.signature`) at the top of the file, before the
`"use cache"` directive.
We can fix this by ensuring that the server action transform (should
really be called "server _function_ transform") runs first.
As a consequence, the transform now needs to be able to parse JSX AST
nodes, which was already explicitly implemented.
closes NAR-130
<!-- 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 #
-->
In development when handling the page request, we are sending the
parsedUrl with the basePath stripped but not assetPrefix. As a result,
when setting an assetPrefix, the chunk would 404 which causes a hard
nav. It'd then recover and work correctly on subsequent navs.
This applies the exact same handling we had for basePath, but for
assetPrefix.
Fixes#77241
Reverts vercel/next.js#79151
It caused a regression like this
```
export type Foo =
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Only async functions are allowed to be exported in a "use server" file.
```
This fixes an error where we incorrectly showed the following compiler
error when using Turbopack:
```sh
Ecmascript file had an error
> 1 | 'use cache'
| ^^^^^^^^^^^
2 |
3 | import { useStuff } from './client-module'
4 |
The "use cache" directive must be at the top of the file.
```
The directive was regarded as not being at the top of the file, because
the React transform (`EcmascriptInputTransform::React`) injects a
variable declaration for React Refresh (e.g. `var _s =
__turbopack_context__.k.signature`) at the top of the file, before the
`"use cache"` directive.
We can fix this by ensuring that the server action transform (should
really be called "server _function_ transform") runs first.
As a consequence, the transform now needs to be able to parse JSX AST
nodes, which was already explicitly implemented.
closes NAR-130
### Why?
This PR initiates the migration of manual testing of the Next.js TypeScript plugin to an automated language service plugin test. It replaced the existing metadata `missing-type-warning` fixture with the `warn-no-type` test (naming for consistency, such as future `error-on-client`).
### Testing Plan
This PR adds the tests and fixtures for the metadata plugin to **warn when no type is provided** for metadata config exports (`metadata` and `generateMetadata`).
1. The fixtures are tested into two categories: 1) "**has type**": expects no warning, and 2) "**no type**": expects a warning.
2. For "has type", the types are from `next` or custom.
3. Each section consists of inline exports and separate exports (`export { ... }`).
4. For the fixtures of `generateMetadata`, it is divided into a function, an arrow function, and a function expression divided with sync and async.
<details><summary>Structure Details</summary>
<p>
#### `metadata`
```
.
├── has-type/
│ ├── export-inline/
│ │ ├── from-next
│ │ └── from-others
│ └── export-separate/
│ ├── from-next
│ └── from-others
└── no-type/
├── export-inline
└── export-separate
```
#### `gerenateMetadata`
```
.
├── has-type/
│ ├── export-inline/
│ │ ├── from-next/
│ │ │ ├── async/
│ │ │ │ ├── arrow-function
│ │ │ │ ├── function-declaration
│ │ │ │ └── function-expression
│ │ │ └── sync/
│ │ │ ├── arrow-function
│ │ │ ├── function-declaration
│ │ │ └── function-expression
│ │ └── from-others/
│ │ ├── async/
│ │ │ └── ...
│ │ └── sync/
│ │ └── ...
│ └── export-separate/
│ ├── from-next/
│ │ ├── async/
│ │ │ └── ...
│ │ └── sync/
│ │ └── ...
│ └── from-others/
│ ├── async/
│ │ └── ...
│ └── sync/
│ └── ...
└── no-type/
├── export-inline/
│ ├── async/
│ │ └── ...
│ └── sync/
│ └── ...
└── export-separate/
├── async/
│ └── ...
└── sync/
└── ...
```
</p>
</details>
### Follow Up
The metadata currently has one more feature: an error when using metadata exports within Client Components.
Jest can run different suites in parallel, but tests within the same suite must run sequentially in the same worker.
You don't want suites that are too small, because each suite requires relatively expensive repository setup, but you also don't want suites that are too large because it inhibits parallelism.
This is a big problem for arewerspackyet, where many of these test cases are currently failing. Each test can take up to 4 minutes to time out, so we easily time out the entire 90 minute long test runner job.
## Test plan
Tested by running all these tests in parallel with:
```
NEXT_TEST_MODE=dev HEADLESS=true node_modules/.bin/jest test/development/pages-dir/client-navigation
```
It completes in about 2m40s minutes on my machine.
rip. you served a purpose once, but now you're just getting in the way. this improves typesafety quite a bit, because `BrowserInterface` had a whole bunch of random `any`s everywhere
also
- removes `evalAsync`. no idea why that was needed, but we're happily using promises in normal eval, so it can be dropped
- adds more safety to `chain`
While working on filesystem watching stuff, I saw that `notify-rs` had a new `with_follow_symlinks` flag, which seems very relevant to us and how we handle symlinks.
When looking to enable this, I noticed that we lacked e2e tests for symlinks. I added a few tests, but found lots of other bugs...
- I ran into https://github.com/vercel/next.js/discussions/77463#discussioncomment-12847522, which I documented, but am not fixing, because it's too far out of scope.
- I ran into a bug with realpath, which is fixed here.
Zack Tanner