Closes WEB-1539
### What?
It looks like there are duplicated codes between `next-font` and `next-transform-font`, and the prior is not being referenced anywhere.
The `libsql` package is a fork of `better-sqlite3` that powers the Turso database client. Let's add `libsql` to the list of external packages, like `better-sqlite3`, so that people don't have to add extra configuration for their Next.js applications.
### What?
Minor PR brings back turbopack beta message. We'll need to improve the actual checks per progress, but that might need auditing what's working vs not later.
Closes WEB-1517
This PR fixes a small issue where we would not save nor read the minimal
server trace file from the cache, meaning that whenever you would do two
builds in a row, the build would skip the tracing of the server as
expected but not include a minimal server trace in the dist folder.
<!-- 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 #
-->
This fixes a "bug" where Sentry was trying to access some of the internal async storages and it would fail because their imports would be compiled as-is instead of using the special rules for Next externals as we are short-cutting it for `next/dist` requests for some reason.
Not a bug per se because this is technically an undocumented API but I think it's a reasonable fix since we don't provide an API for that. The alternative for them would be to try to play around with the bundling, which is not a good use of anyone's time.
### What
Found a flaky test like https://github.com/vercel/next.js/actions/runs/6125719281/job/16628276301?pr=55118#step:29:174, `get-port` throws by port is not available. Peeking bit, there seems an upstream fix hope to improve the situation but unfortunately it happened after get-port switched to native esm only, so bumping is non trivial work. Instead adapting get-port-please as a replacwement but leave get-port as fallback for a while to verify its stability. Once we are certain, we can remove old get-port entirely.
Closes WEB-1518
### What?
This PR refactors test cases from next-dev, tests basic tailwind rendering with turbopack. It still runs against plain next.js too. While checking, noticed there's a stub fixture (css-fixture/with-tailwindcss) but those fixture seems not being used in the test. Moved those and utilized. Since this test runs against next.js / turbopack both anyway, moving fixture should not be a huge regression I believe.
### What?
https://vercel.slack.com/archives/C04KC8A53T7/p1694190462958199
I realized we throws an error attempt to destory against undefined instance when `beforeAll` fails in any reason. This is quite redundant error since if next instance doesn't exist, likely there's an upstream test failures already and destory against undefined error is not useful to debug anyway.
PR replaces `nextTestSetup`'s teardown first, for the remaining places calling `next.destory` explicitly will be amended later.
### Why?
The `ImageResponse` class constructor returns a `Response` instance, but doesn't extend `Response`, so it doesn't pass the type check introduced in #51394.
### How?
Make the `ImageResponse` class a subclass of `Response`.
### Notes
I can't find any tests to check for the types so didn't add any tests here; but shouldn't there be one?
This PR tweaks the webpack config so that when we compile user code with webpack, we remove all branches of code that are guarded with `process.env.TURBOPACK`. I noticed that the bundle runtime was not tree-shaken correctly, this fixes that.
This PR fixes a bug in the require hook implementation where the variable used might not exist depending on the environment. In order to fix that, we can use the variable used to define the version of React used instead as it is already present and a proxy of the same information.
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
### What?
Fixes#51130. Before this PR, the package assumes that route handlers return a `Response` which is not necessarily the case.
The linked issue specified three suggestions to resolve this
1. Return a default 200 response
2. Throw a better error message
3. or both
~~In this issue I implemented (3), except that it is a warning and not an error. Do tell if the team wants to follow a different approach, as it is not too hard to change this.~~
This PR implements (2).
### How?
The returned value of the handler is checked at runtime to ensure it is actually a `Response` instance.
The return type `AppRouteHandlerFn` is also modified to `unknown` to avoid similar assumptions elsewhere.
The TS plugin is also modified to check for the return type during build time.
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
Only output app routes if there's no pages routes in next build output
For hello world app you'll only see app dir routes
```
Route (app) Size First Load JS
+ First Load JS shared by all 78.1 kB
├ chunks/main-app-e4c0616da69beffe.js 76.5 kB
└ chunks/webpack-bf1a64d1eafd2816.js 1.61 kB
○ (Static) automatically rendered as static HTML (uses no initial props)
```
Also filter out `/favicon.ico` static route as it's confusing
