a9b9e00703
Makes it possible to switch between edge/server runtime in dev without breaking the server. Fixes slack: [1](https://vercel.slack.com/archives/CGU8HUTUH/p1659082535540549) [2](https://vercel.slack.com/archives/C02CDC2ALJH/p1658978287244359) [3](https://vercel.slack.com/archives/C03KAR5DCKC/p1656869427468779) #### middleware-plugin.ts `middlewareManifest` moved from module scope to local scope. Stale state from earlier builds ended up in `middleware-manifest.json`. Functions that changed from edge to server runtime stayed in the manifest as edge functions. #### on-demand-entry-handler.ts When a server or edge entry is added we check if it has switched runtime. If that's the case the old entry is removed. #### Reproduce Create edge API route and visit `/api/hello` ```js // pages/api/hello.js export const config = { runtime: 'experimental-edge', } export default () => new Response('Hello') ``` Change it to a server api route and visit `/api/hello`, it will explode. ```js // pages/api/hello.js export default function (req, res) { res.send('Hello') } ``` #### Bug not fixed One EDGE case is not fixed. It occurs if you switch between edge and server runtime several times without changing the content of the file: Edge runtime ```js export const config = { runtime: 'experimental-edge', } export default () => new Response('Hello') ``` Change it to a server runtime ```js export default function (req, res) { res.send('Hello') } ``` Change back to edge runtime, the content of the file is the same as the first time we compiled the edge runtime version. ```js export const config = { runtime: 'experimental-edge', } export default () => new Response('Hello') ``` The reason is that both the edge and server compiler emits to the same file (/.next/server/pages/api/hello.js) which makes this check fail in webpack: https://github.com/webpack/webpack/blob/main/lib/Compiler.js#L849-L861 Possible solution is to use different output folders for edge and server https://vercel.slack.com/archives/CGU8HUTUH/p1661163106667559 Co-authored-by: JJ Kasper <jj@jjsweb.site> |
||
---|---|---|
.. | ||
.stats-app | ||
__mocks__ | ||
development | ||
e2e | ||
integration | ||
lib | ||
production | ||
unit | ||
.gitignore | ||
jest-setup-after-env.ts | ||
jest.d.ts | ||
readme.md | ||
test-file.txt |
Writing tests for Next.js
Getting Started
You can set-up a new test using yarn new-test
which will start from a template related to the test type.
Test Types in Next.js
- e2e: These tests will run against
next dev
,next start
, and deployed to Vercel - development: These tests only run against
next dev
- production: These tests will run against
next start
. - integration: These tests run misc checks and modes and is where tests used to be added before we added more specific folders. Ideally we don't add new test suites here as tests here are not isolated from the monorepo.
- unit: These are very fast tests that should run without a browser or running next and should be testing a specific utility.
For the e2e, production, and development tests the createNext
utility should be used and an example is available here. This creates an isolated Next.js install to ensure nothing in the monorepo is relied on accidentally causing incorrect tests.
All new test suites should be written in TypeScript either .ts
(or .tsx
for unit tests). This will help ensure we catch smaller issues in tests that could cause flakey or incorrect tests.
If a test suite already exists that relates closely to the item being tested (e.g. hash navigation relates to existing navigation test suites) the new checks can be added in the existing test suite.
Best Practices
- When checking for a condition that might take time, ensure it is waited for either using the browser
waitForElement
or using thecheck
util innext-test-utils
. - When applying a fix, ensure the test fails without the fix. This makes sure the test will properly catch regressions.
Helpful environment variables
There are some test specific environment variables that can be used to help debug isolated tests better, these can be leveraged by prefixing the pnpm testheadless
command.
- When investigating failures in isolated tests you can use
NEXT_TEST_SKIP_CLEANUP=1
to prevent deleting the temp folder created for the test, then you can runpnpm next
while inside of the temp folder to debug the fully setup test project. - You can also use
NEXT_SKIP_ISOLATE=1
if the test doesn't need to be installed to debug and it will run inside of the Next.js repo instead of the temp directory, this can also reduce test times locally but is not compatible with all tests. - The
NEXT_TEST_MODE
env variable allows toggling specific test modes for thee2e
folder, it can be used when not usingpnpm test-dev
orpnpm test-start
directly. Valid test modes can be seen here:aa664868c1/test/lib/e2e-utils.ts (L46)
Debugging
When tests are run in CI and a test failure occurs we attempt to capture traces of the playwright run to make debugging the failure easier. A test-trace artifact should be uploaded after the workflow completes which can be downloaded, unzipped, and then inspected with pnpm playwright show-trace ./path/to/trace