It compiles fine, but we have another problem: `cargo fmt` really doesn't like it
```
cargo fmt -- turbopack/crates/turbo-tasks-fs/src/lib.rs
error: let chains are only allowed in Rust 2024 or later
--> /Users/niklas/code/next.js/turbopack/crates/turbo-tasks-fs/src/lib.rs:749:44
|
749 | if create_directory && let Some(parent) = full_path.parent() {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: let chains are only allowed in Rust 2024 or later
--> /Users/niklas/code/next.js/turbopack/crates/turbo-tasks-fs/src/lib.rs:893:44
|
893 | if create_directory && let Some(parent) = full_path.parent() {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
error: let chains are only allowed in Rust 2024 or later
--> /Users/niklas/code/next.js/turbopack/crates/turbo-tasks-fs/src/lib.rs:1233:12
|
1233 | if let Some(path) = join_path(&self.path, path)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
The precommit hook that selectively runs on files is simply not a supported usecase.
So I changed that to `rustfmt --edition 2024 -- ` now 🤷
Previous discussion: https://vercel.slack.com/archives/C03EWR7LGEN/p1748898285716779
Devcontainers support custom `Dockerfile`s, but it seems like it's more recommended to use a base image with "features" on top: https://containers.dev/implementors/features/
Features get applied after the `Dockerfile`, so e.g. if we're installing `rust` with a feature, then we can't install things that depend on `rust` (e.g. `cargo-nextest`: https://nexte.st/) in the `Dockerfile`. So you're forced to do things with features instead, which can specify dependencies and ordering requirements.
I removed a bunch of comments that were left over from the template. People wishing to update this file should refer to the https://aka.ms/devcontainer.json link at the top of the file.
Also added a lockfile for the features, generated with:
```
devcontainer upgrade --workspace-folder=.
```
**Note:** The `base.Dockerfile` here was entirely unused.
### Testing
```
podman stop --all && podman rm --all # replace podman with docker if you're using docker
devcontainer up --workspace-folder=.
devcontainer exec --workspace-folder=. zsh
```
### What?
enables the next-dev-tests crate integration tests from trubopack
### Why?
to unblock the move PR we temporarily disabled the tests
### How?
Fix the new location and fix the expect dependency
Fixes WEB-708
---------
Co-authored-by: Justin Ridgewell <justin@ridgewell.name>
This removes the `--net=host` argument passed to the devcontainer.
Originally introduced for X11 forwarding, devcontainer already passes
`--network host` argument doing the same
[thing](https://stackoverflow.com/q/50644889/8429267)?
Check the build logs
```
Start: Run: docker run --sig-proxy=false -a STDOUT -a STDERR --mount type=bind,src=/var/lib/docker/codespacemount/workspace,dst=/workspaces --mount source=/root/.codespaces/shared,target=/workspaces/.codespaces/shared,type=bind --mount source=/var/lib/docker/codespacemount/.persistedshare,target=/workspaces/.codespaces/.persistedshare,type=bind --mount source=/.codespaces/agent/mount,target=/.codespaces/bin,type=bind --mount source=/mnt/containerTmp,target=/tmp,type=bind --mount type=bind,src=/.codespaces/agent/mount/cache,dst=/vscode -l Type=codespaces -e CODESPACES=true -e ContainerVersion=12 -e RepositoryName=next.js --label ContainerVersion=12 --hostname codespaces-9b31fb --add-host codespaces-9b31fb:127.0.0.1 --cap-add sys_nice --network host --cap-add SYS_PTRACE --security-opt seccomp=unconfined --entrypoint /bin/sh vsc-next.js-e4966344b9ebb252cd82cad8e4b143f1 -c echo Container started
```
[Refer](https://github.com/vercel/next.js/pull/43138#issuecomment-1328026282)
for original issue with the current configuration. Closes#43451
P.S. Why do we have X11 support in devcontainers in the first place? Its
not something *most* people will use, especially if it comes with the
cost of codespaces not working. Need someone to verify if X11 forwarding
still works with this configuration as it probably should.
Benjamin Woodruff