You'll probably want to disable whitespace in the diff
## Description
This allows for better editor support by using `describe` or functions called `describe` with the same syntax instead of custom names.
Changes:
- `nextTestSetup` can be used instead of `createNextDescribe` keeping the same behaviour but being called inside a `describe` "block" (not applied everywhere)
- `getSnapshotTestDescribe` replaced with a custom `describe.each`
- `sandbox` helper function for `acceptance`/`acceptance-app` merged into a single shared one
- `outdent` to remove the indent from inline files in tests which helps with consistent snapshots
Reverts vercel/next.js#51406
This pnpm bump seems to be causing lockfile issues with the react
versions which causes context issues since we need to share the same
react version in the monorepo.
### What?
Fixespnpm/pnpm#6424
### Why?
So users of Node 20 can contribute to Next.js
### How?
Upgrades pnpm with back compatibility to patch `ERR_INVALID_THIS` error.
If Node 14 support isn't necessary, I'd recommend upgrading to pnpm 8
for continued feature support and committing the lockfile.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
WEB-1150.
This PR is an attempt to upload next.js's test results into datadog test trace to track its status.
Originally it tried to use automatic trace injection (dd-trace/ci/init). However, due to some of custom environments / setup we use it was not compatible out of the box. Instead, this PR injects a new test reportert to generate junit report, then upload it at once at the end of the testing pipeline.
The reporter is configured to run when necessary variables set, local run should not be affected.
One thing to note is this report will not count retry results, as it'll create duplicated test entry with multiple results since we runts jest per individual test. This'll allow to detect flaky test easier, but also it means we'll get bit of skewed test results compare to the real world as first failure will be accounted as test fail immediately.
There are some incoming docs / MDX changes where prettier will throw an error when using the older version. Updating prettier before I bring in those changes.
Looks like the most notable change is adding parentheses around `typeof` checks in TypeScript.
**Before**
```
export type Locale = typeof i18n['locales'][number]
```
**After**
```
export type Locale = (typeof i18n)['locales'][number]
```
To resolve issue #49382, we found layer doesn't get applied for dynamic imports, so we fixed it on webpack side in https://github.com/webpack/webpack/pull/17310
This PR is to upgrade webpack to 5.86.0 with that patch as a precedence. After this we need to fix the `next/image` client components is missing in client reference manifest when using dynamic imports to fix the issue.
For RSC server layer so far we bundle all dependencies, ESM format is the better one rather than CJS to analyze and tree-shake out the unused parts. This PR changes pick the condition names that are in ESM format first for server layer.
Also fixes the misorder of condition names of edge runtime, `conditionNames` should only contain either ESM or CJS, previously the main fields are mixed with conditon names which is not expected for webpack, we separate them now.
Since we're picking ESM instead CJS now, the error of require `exports * from` doesn't exist anymore, but if you're using a CJS dependency which require a ESM package, it will error. This is the existing behavior for our webpack configuration but could happen on server layer bundling
Other related changes:
* Imports are hoisted in ESM, so migrate`enhanceGlobals` to a imported module
* Use `...` to pick the proper imports by import expression, and prefer the `react-server` / `edge-light` condition names for corresponding cases
* Remove edge SSR duplicated `middleware` export checking
### What?
Another attempt to https://github.com/vercel/next.js/pull/50619 and WEB-1150, trying to apply setup guard more throughly.
I still do not know why original PR passed CI but fails to subsequent PRs after merge, but hope this could be a right guard to prevent unexpected failures.
Hello,
We removed some core non-necessary dependencies that make Edge Runtime
smaller 🙂.
Also, Edge Runtime is exposing `WebSocket`, so nothing additional should
be done.
Closes https://github.com/vercel/next.js/issues/50760
---------
Co-authored-by: Wyatt Johnson <accounts+github@wyattjoh.ca>
Bumping `@edge-runtime/*` <picture data-single-emoji=":edge-runtime:" title=":edge-runtime:"><img class="emoji" width="20" height="auto" src="https://emoji.slack-edge.com/T0CAQ00TU/edge-runtime/b940e917443aa49f.png" alt=":edge-runtime:" align="absmiddle"></picture> packages to their latest beta, as we had some huge improvements and big changes on how it works internally.
* Using the latest `undici` which provides a WebSocket implementation
* Less polyfill usage as we load modules in the Node.js realm, and can reuse modules from Node.js as time goes on <picture data-single-emoji=":just-right2:" title=":just-right2:"><img class="emoji" width="20" height="auto" src="https://emoji.slack-edge.com/T0CAQ00TU/just-right2/588cf34d02f4b3bd.png" alt=":just-right2:" align="absmiddle"></picture>
* `instanceof` checks now work within the realm <picture data-single-emoji=":mind_blown:" title=":mind_blown:"><img class="emoji" width="20" height="auto" src="https://emoji.slack-edge.com/T0CAQ00TU/mind_blown/0186b6f181040126.gif" alt=":mind_blown:" align="absmiddle"></picture>
This adds new `build and test` and `build and deploy` workflows in favor
of the existing massive `build, test, and deploy` workflow. Since the
new workflows will use `pull_request_target` this waits to remove the
existing workflow until the new one is tested.
While testing this new workflow flakey behavior in tests have also been
addressed. Along with the new workflow we will also be leveraging new
runners which allow us to run tests against the production binary of
`next-swc` so this avoids slight differences in tests we've seen due to
running against the dev binary.
Furthermore we will have a new flow for allowing workflow runs on PRs
from external forks which will either require a comment be checking a
box approving the run after each change or a label added by the team.
The new flow also no longer relies on `actions/cache` or similar which
have proven to be pretty unreliable.
Tests runs with the new workflow can be seen here
https://github.com/vercel/next.js/actions/runs/5100673508/jobs/9169416949
This PR does three things:
- Vendors the package `react-server-dom-webpack@experimental` as
`react-server-dom-webpack-experimental` similar to React and React DOM
- Upgrades all vendored React packages
- Re-lands the `experimentalReact` flag to switch between `@next` and
`@experimental` channels of React for app dir.
Fix NEXT-926.
### What?
Exposing `globalThis.crypto`, based on [Node.js' WebCrypto
API](https://nodejs.org/api/globals.html#crypto_1)
### Why?
Similar to `fetch`, `crypto` is a popular API that is currently not
available on `globalThis` in all active Node.js versions yet.
This can help library authors to create runtime-agnostic packages.
### How?
Node.js already has the WebCrypto API that can be imported, we just
expose it on `globalThis` in Node.js versions where this is not
available.
Closes NEXT-1063
[Slack
thread](https://vercel.slack.com/archives/C03KAR5DCKC/p1681821510191059)
This PR implements preloading of CSS from RSC.
1. The underlying Flight protocol was extended in
https://github.com/facebook/react/pull/26502 to allow sending hints from
RSC to SSR and Client runtimes. React was updated to include these
changes.
2. We now call `ReactDOM.preload()` for each stylesheet used in a
layout/page layer
There are a few implementation details to take note of
1. we were previously using the `.browser` variant of a few React
packages. This was a holdover from when there was just browser and node
and we wanted to use the browser variant b/c we wanted the same code to
work in edge/node runtimes. React now publishes a `.edge` variant which
is like `.browser` but expects to be server only. This is necessary to
get the opt-in for `AsyncLocalStorage`.
2. Even with the above change, AsyncLocalStorage was not patched on the
global scope until after React was loaded. I moved this into a module
which is loaded first
3. The component passed to RSC's `renderToReadableStream` is not
actually part of the RSC module graph. If I tried to call
`ReactDOM.preload()` inside that function or any other function defined
inside `app-render.tsx` file it would actually see the wrong instance of
`react-dom`. I added a new export on the RSC top level export which
exposes a `preloadStyle(...)` function which just delegates to
`ReactDOM.preload(...)`. This makes the preload run in the right module
graph
~There are a couple of bugs in React that this work uncovered that I
will upstream. We may want to delay merging until they are addressed.
I'll update this comment when that is complete.~
1. ~React, during SSR, can emit a preload for a style twice in some
circumstances because late discovered stylesheets don't consider whether
a preload has already been flushed when preparing to reveal a boundary
they are within~
2. ~React, during RSC updates on the client, can preload a style that is
already in the document because it currently only looks for existing
preload links and does not consider if there is a stylesheet link with
the same href.~
~both of these issues will not break functionality, they just make the
network tab look at bit more noisy. We would expect network deduping to
prevent multiple actual loads~
The above React bugs were fixed and included now in the React update in
this PR
---------
Co-authored-by: Shu Ding <g@shud.in>
Part of #47759 (which had been reverted twice so here we only land a part of the change), relates to NEXT-926. Thanks to #48506 we can soon switch between these two channels during runtime.
Also fixes a problem of `renderKind` (only revealed after upgrading React), it should be also based on the `match` kind.
### What?
Update `@swc/helpers` to `v0.5.1`.
### Why?
Webpack merges `@swc/helpers@v0.4.x` and `@swc/helpers@v0.5.x`, due to `resolve.alias` config in 2f6ff0dab3/packages/next/src/build/webpack-config.ts (L1070-L1072)
To workaround it, `@swc/helpers@v0.5.1` reexports from entries just like `v0.4`.
### How?
Closes WEB-948
Fixes#48593
We decided in https://github.com/vercel/next.js/pull/48308 that we won't
use `turbo` when packing packages for tests.
This PR removes all code associated with that effort. The whole thing
fas behind a flag, so it shouldn't affect anything.
fix NEXT-1025
Reverts vercel/next.js#48038
fix NEXT-926
---
The root cause was that when copying the package.json, I removed all
fields except for a few (such as `exports`) but missed the `browser`
field. That caused the client bundle to resolve to the Node.js version
of React DOM, and then we had the `async_hooks` error. Added it back in
99c9b9e51f8b0d4e4503ece9d07bce09161f3341.
I reproduced the error with next-site earlier and confirmed that this
fix is good.
