### What?
This PR makes it easier to use Next.js with IPv6 hostnames such as `::1` and `::`.
### How?
It does so by removing rewrites from `localhost` to `127.0.0.1` introduced in #52492. It also fixes the issue where Next.js tries to fetch something like `http://::1:3000` when `--hostname` is `::1` as it is not a valid URL (browsers' `URL` class throws an error when constructed with such hosts). It also fixes `NextURL` so that it doesn't accept `http://::1:3000` but refuse `http://[::1]:3000`. It also changes `next/src/server/lib/setup-server-worker.ts` so that it uses the server's `address` method to retrieve the host instead of our provided `opts.hostname`, ensuring that no matter what `opts.hostname` is we will always get the correct one.
### Note
I've verified that `next dev`, `next start` and `node .next/standalone/server.js` work with IPv6 hostnames (such as `::` and `::1`), IPv4 hostnames (such as `127.0.0.1`, `0.0.0.0`) and `localhost` - and with any of these hostnames fetching to `localhost` also works. Server Actions and middleware have no problems as well.
This also removes `.next/standalone/server.js`'s logging as we now use `start-server`'s logging to avoid duplicates. `start-server`'s logging has also been updated to report the actual hostname.
The above pictures also demonstrate using Server Actions with Next.js after this PR.
Fixes#53171Fixes#49578
Closes NEXT-1510
Co-authored-by: Tim Neutkens <6324199+timneutkens@users.noreply.github.com>
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
Adding `nextConfig.output` to next-info output so that we could determine if users're using standalone mode if the reproduction is not clear or missing sometimes
Example output
```
Relevant Packages:
next: 13.4.8-canary.1
eslint-config-next: 13.4.8-canary.1
react: 18.2.0
react-dom: 18.2.0
typescript: 5.1.3
Next.js Config:
output: standalone
```
### What?
Add all available options to cli commands
Consistent formatting for all options
### Why?
Options were not consistent across all commands, some were missing
Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
This ensures we don't fail to return the full body when storing to
fetch-cache in edge-runtime. Also ensures the fetch cache tests are
running for Node.js v16 correctly.
Fetch handling was also failing on Node.js v16 due to react's use of
`res.clone()` being broken with undici which is fixed in the latest
version of edge-runtime so this bumps that.
x-ref: [slack
thread](https://vercel.slack.com/archives/C03S8ED1DKM/p1681310566927429)
This updates to have a separate routing process and separate rendering
processes for `pages` and `app` so that we can properly isolate the two
since they rely on different react versions.
Besides allowing the above mentioned isolation this also helps us
control recovering from process crashes easier as pieces are more
isolated from one another e.g. an infinite loop during rendering will no
longer block the compiler and can be stopped/restarted as needed.
In follow-up PRs we will continue to separate out the routing logic from
the rendering logic so that each process only loads what is relevant to
it helping simplify the flow for requests regardless of type.
---------
Co-authored-by: Shu Ding <g@shud.in>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This addresses a bug where invoking `next dev` or `next start` with `--port 0` would fall back to the default port of 3000 instead of binding to port 0 (which typically results in the operating system assigning a free port).
I couldn't find a straightforward way of adding a test for next-start. It looks like we could add a similar test as for dev, but would need to generate a built project to serve.
Manual test plan for `next start`:
```
$ ./packages/next/dist/bin/next start --port 0
ready - started server on 0.0.0.0:53508, url: http://localhost:53508
```
## Bug
- [ ] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm lint`
- [ ] The examples guidelines are followed from [our contributing doc](https://github.com/vercel/next.js/blob/canary/contributing.md#adding-examples)
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: Wyatt Johnson <accounts+github@wyattjoh.ca>
I noticed a few issues that had "Output from `next info`" with the first line as
```
/bin/sh: pnpm: command not found
```
This was because `execSync()` was still printing to stderr when a command was not found.
Changing to `execFileSync()` fixed it so we no longer print to stderr when a command is not found.
This PR adds a new command to the `next` CLI.
Running `next info` will print useful information to the terminal about how/where Next.js is run. This information can be added to the Bug report when opening an issue in the repository.
This makes reporting issues more accurate and doesn't require the user to guess certain details, the command will retrieve it on their behalf.
Example output:
```sh
$ npx --no-install next info
Operating System:
Platform: linux
Version: #22-Ubuntu SMP Fri Nov 5 13:21:36 UTC 2021
Binaries:
Node: 16.13.0
npm: 8.1.0
Yarn: 1.22.17
pnpm: 6.24.2
Relevant packages:
next: 12.0.8-canary.14
react: 17.0.2
react-dom: 17.0.2
```
The idea is based on #32858
## Bug
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Errors have helpful link attached, see `contributing.md`
## Feature
- [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR.
- [ ] Related issues linked using `fixes #number`
- [ ] Integration tests added
- [ ] Documentation added
- [ ] Telemetry added. In case of a feature if it's used or not.
- [ ] Errors have helpful link attached, see `contributing.md`
## Documentation / Examples
- [ ] Make sure the linting passes by running `yarn lint`
Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
Fixes#16173
## What
Restores handling of termination signals, `SIGTERM` and `SIGINT`, to allow graceful termination of next commands. Seems to have been removed during a child process refactor #6450, was this intentional?
## Why
Currently the command processes have to be forcefully killed. This would help those using Next.js with custom servers and tools like Docker and Kubernetes that rely on termination signals to shutdown instances.
---
Where would be a good location to add some tests? [test/integration/cli/test/index.test.js](fc98c13a2e/test/integration/cli/test/index.test.js)?
Fixes#15928
---
This would cause us to print the message too early and open the browser to a server that wasn't started yet. This waits until we're listening, but before the app is ready fully.
* fix(debugging): do not pass NODE_OPTIONS='--inspect' to subprocesses
fixes#11030
* fix(debugger): use a regex to remove bad NODE_OPTIONS flags
Co-authored-by: Alec Larson <alec.stanford.larson@gmail.com>
* Do not clear the console
Its rude to clear the console, you may be sharing output with other processes even in tty mode.
* Remove unused dependency
* Dedupe and cleanup dev output without clearing
* use logError
* Remove exit handler
* Add next helper
* Add log helpers
* Switch store to log helpers and a shallow object compare
* Update other files to use new logging utility
* request => build
* Update ready on messages
* Use case insensitive matching
This message is from @timneutkens after making changes:
- Convert executables to Typescript
- Remove `minimist` in favor of `arg`
- Implement `--node-args` usage: `--node-args="--throw-deprecation"`
- Adds tests for usage of the `next` cli
