25 files changed, 0 insertions, 1175 deletions

diff --git a/docs/pages/pack/_meta.json b/docs/pages/pack/_meta.json
deleted file mode 100644
index 4941080..0000000
--- a/docs/pages/pack/_meta.json
+++ /dev/null
@@ -1,15 +0,0 @@
-{
-  "index": {
-    "type": "page",
-    "display": "hidden",
-    "theme": {
-      "layout": "raw",
-      "sidebar": false,
-      "toc": true
-    }
-  },
-  "docs": {
-    "title": "Docs",
-    "display": "children"
-  }
-}
diff --git a/docs/pages/pack/docs/_meta.json b/docs/pages/pack/docs/_meta.json
deleted file mode 100644
index ddd6017..0000000
--- a/docs/pages/pack/docs/_meta.json
+++ /dev/null
@@ -1,10 +0,0 @@
-{
-  "index": "Quickstart",
-  "why-turbopack": "Why Turbopack?",
-  "core-concepts": "Core Concepts",
-  "roadmap": "Roadmap",
-  "features": "Features",
-  "comparisons": "Comparisons",
-  "benchmarks": "Benchmarks",
-  "migrating-from-webpack": "Migrating from Webpack"
-}
diff --git a/docs/pages/pack/docs/advanced/profiling.mdx b/docs/pages/pack/docs/advanced/profiling.mdx
deleted file mode 100644
index 7c50d18..0000000
--- a/docs/pages/pack/docs/advanced/profiling.mdx
+++ /dev/null
@@ -1,74 +0,0 @@
----
-title: Profiling
-description: Learn how to profile Turbopack
----
-
-import { ThemedImageFigure } from '../../../../components/image/ThemedImageFigure';
-
-# Profiling Turbopack
-
-## On macOS
-
-### Install [`cargo-instruments`]
-
-```sh
-cargo install cargo-instruments
-```
-
-Make sure you have all the [prerequisites](https://github.com/cmyr/cargo-instruments#pre-requisites) for running cargo-instruments.
-
-### Run the profiler
-
-By default, the next-dev CLI will keep watching for changes to your application and never exit until you manually interrupt it. However, [`cargo-instruments`] waits for your program to exit before building and opening the trace file. For this purpose, we've added a `profile` feature to `next-dev` which exits the program if no updates are detected within a given time frame and there are no pending tasks.
-
-To profile `next-dev`, run the following command:
-
-```sh
-cargo instruments -t time --bin next-dev --release --features profile [-- [...args]]
-```
-
-You can also run [other templates](https://github.com/cmyr/cargo-instruments#templates) than the time profiler.
-
-Once the program exits, the profiler will open the trace file in Instruments. Refer to the [learning resources](https://github.com/cmyr/cargo-instruments#resources) to learn how to use Instruments.
-
-<ThemedImageFigure
-  borderRadius={true}
-  dark={{
-    source: '/images/docs/pack/instruments-dark.png',
-    height: 662,
-    width: 968
-  }}
-  light={{
-    source: '/images/docs/pack/instruments-light.png',
-    height: 706,
-    width: 1012
-  }}
-  captionSpacing={24}
-  caption="An example trace from the time profiler."
-/>
-
-## Linux
-
-### Memory usage
-
-```sh
-# Install `heaptrack` and `heaptrack_gui`
-sudo apt install heaptrack heaptrack_gui
-
-# Compile with debug info but without the alternative allocator:
-CARGO_PROFILE_RELEASE_DEBUG=1 cargo build --bin next-dev --release --no-default-features --features cli
-
-# Run the binary with heaptrack (it will be much slower than usual)
-heaptrack target/release/next-dev [...]
-
-# Stop it anytime
-
-# Open the GUI and open the heaptrack.next-dev.XXX.gz file
-heaptrack_gui
-```
-
-## On other platforms
-
-We currently don't have a guide for profiling Turbopack on other platforms.
-
-[`cargo-instruments`]: https://github.com/cmyr/cargo-instruments
diff --git a/docs/pages/pack/docs/benchmarks.mdx b/docs/pages/pack/docs/benchmarks.mdx
deleted file mode 100644
index 41788a9..0000000
--- a/docs/pages/pack/docs/benchmarks.mdx
+++ /dev/null
@@ -1,174 +0,0 @@
-import { DEFAULT_BARS } from '../../../components/pages/pack-home/PackBenchmarks'
-import { DocsBenchmarksGraph } from '../../../components/pages/pack-home/DocsBenchmarksGraph';
-import Callout from '../../../components/Callout';
-import { ThemedImageFigure } from '../../../components/image/ThemedImageFigure';
-import { HMR_BARS } from '../../../components/pages/pack-home/PackBenchmarks'
-
-# Benchmarks
-
-We created a test generator that makes an application with a variable amount of modules to benchmark cold startup and file updating tasks. This generated app includes entries for these tools:
-
-- Next.js 11
-- Next.js 12
-- Next.js 13 with Turbopack
-- Vite
-
-As the current state of the art, we're including [Vite](https://vitejs.dev/) along with webpack-based [Next.js](https://nextjs.org) solutions. All of these toolchains point to the same generated component tree, assembling a [Sierpiński triangle](https://en.wikipedia.org/wiki/Sierpi%C5%84ski_triangle) in the browser, where every triangle is a separate module.
-
-<ThemedImageFigure
-  borderRadius={false}
-  dark={{
-    source: '/images/blog/turbopack-benchmarks/triangle-dark.png',
-    height: 600,
-    width: 1200
-  }}
-  light={{
-    source: '/images/blog/turbopack-benchmarks/triangle-light.png',
-    height: 600,
-    width: 1200
-  }}
-  captionSpacing={-12}
-  caption="This image is a screenshot of the test application we run our benchmarks on. It depicts a Sierpiński triangle where each single triangle is its own component, separated in its own file. In this example, there are 3,000 triangles being rendered to the screen."
-/>
-
-## Metrics
-
-Let's break down exactly what each of these metrics mean, and how they'll impact your day-to-day developer experience.
-
-<Callout type="info">
-  Curious about how these benchmarks are implemented, or want to run them yourself? Check out [our benchmark suite documentation in the Turbo monorepo](https://github.com/vercel/turbo/blob/main/crates/next-dev/benches/README.md).
-</Callout>
-
-### Cold startup time
-
-This test measures how fast a local development server starts up on an application of various sizes. We measure this as the time from startup (without cache) until the app is rendered in the browser. We do not wait for the app to be interactive or hydrated in the browser for this dataset.
-
-<DocsBenchmarksGraph category="cold" bars={DEFAULT_BARS} />
-
-<ThemedImageFigure
-  borderRadius={true}
-  dark={{
-    source: '/images/blog/turbopack-benchmarks/bench_startup_dark.svg',
-    height: 720,
-    width: 1960
-  }}
-  light={{
-    source: '/images/blog/turbopack-benchmarks/bench_startup_light.svg',
-    height: 720,
-    width: 1960
-  }}
-  captionSpacing={24}
-  caption="Startup time by module count. Benchmark data generated from 16” MacBook Pro 2021, M1 Max, 32GB RAM, macOS 13.0.1 (22A400)."
-/>
-
-#### Data
-
-To run this benchmark yourself, clone [`vercel/turbo`](https://github.com/vercel/turbo) and then use this command from the root:
-
-```sh
-TURBOPACK_BENCH_COUNTS=1000,5000,10000,30000 TURBOPACK_BENCH_BUNDLERS=all cargo bench -p next-dev "startup/(Turbopack SSR|Next.js 12 SSR|Next.js 11 SSR|Vite SWC CSR)."
-```
-
-Here are the numbers we were able to produce on a 16” MacBook Pro 2021, M1 Max, 32GB RAM, macOS 13.0.1 (22A400):
-
-```sh
-bench_startup/Next.js 11 SSR/1000 modules                  9.2±0.04s
-bench_startup/Next.js 11 SSR/5000 modules                 32.9±0.67s
-bench_startup/Next.js 11 SSR/10000 modules                71.8±2.57s
-bench_startup/Next.js 11 SSR/30000 modules               237.6±6.43s
-bench_startup/Next.js 12 SSR/1000 modules                  3.6±0.02s
-bench_startup/Next.js 12 SSR/5000 modules                 12.1±0.32s
-bench_startup/Next.js 12 SSR/10000 modules                23.3±0.32s
-bench_startup/Next.js 12 SSR/30000 modules                89.1±0.21s
-bench_startup/Turbopack SSR/1000 modules               1381.9±5.62ms
-bench_startup/Turbopack SSR/5000 modules                   4.0±0.04s
-bench_startup/Turbopack SSR/10000 modules                  7.3±0.07s
-bench_startup/Turbopack SSR/30000 modules                 22.0±0.32s
-bench_startup/Vite SWC CSR/1000 modules                    4.2±0.02s
-bench_startup/Vite SWC CSR/5000 modules                   16.6±0.08s
-bench_startup/Vite SWC CSR/10000 modules                  32.3±0.12s
-bench_startup/Vite SWC CSR/30000 modules                  97.7±1.53s
-```
-
-### File updates (HMR)
-
-We also measure how quickly the development server works from when an update is applied to a source file to when the corresponding change is re-rendered in the browser.
-
-For Hot Module Reloading (HMR) benchmarks, we first start the dev server on a fresh installation with the test application. We wait for the HMR server to boot up by running updates until one succeeds. We then run ten changes to warm up the tooling. This step is important as it prevents discrepancies that can arise with cold processes.
-
-Once our tooling is warmed up, we run a series of updates to a list of modules within the test application. Modules are sampled randomly with a distribution that ensures we test a uniform number of modules per module depth. The depth of a module is its distance from the entry module in the dependency graph. For instance, if the entry module A imports module B, which imports modules C and D, the depth of the entry module A will be 0, that of module B will be 1, and that of modules C and D will be 2. Modules A and B will have an equal probability of being sampled, but modules C and D will only have half the probability of being sampled.
-
-We report the linear regression slope of the data points as the target metric. This is an estimate of the average time it takes for the tooling to apply an update to the application.
-
-<DocsBenchmarksGraph category="file_change" bars={HMR_BARS} />
-
-<ThemedImageFigure
-  borderRadius={true}
-  dark={{
-    source: '/images/blog/turbopack-benchmarks/bench_hmr_to_commit_dark.svg',
-    height: 720,
-    width: 1960
-  }}
-  light={{
-    source: '/images/blog/turbopack-benchmarks/bench_hmr_to_commit_light.svg',
-    height: 720,
-    width: 1960
-  }}
-  captionSpacing={24}
-  caption="Turbopack, Next.js (webpack), and Vite HMR by module count. Benchmark data generated from 16” MacBook Pro 2021, M1 Max, 32GB RAM, macOS 13.0.1 (22A400)."
-/>
-
-<a id="bench"/>
-
-<ThemedImageFigure
-  borderRadius={true}
-  dark={{
-    source: '/images/blog/turbopack-benchmarks/bench_hmr_to_commit_turbopack_vite_dark.svg',
-    height: 720,
-    width: 1960
-  }}
-  light={{
-    source: '/images/blog/turbopack-benchmarks/bench_hmr_to_commit_turbopack_vite_light.svg',
-    height: 720,
-    width: 1960
-  }}
-  captionSpacing={24}
-  caption="Turbopack and Vite HMR by module count. Benchmark data generated from 16” MacBook Pro 2021, M1 Max, 32GB RAM, macOS 13.0.1 (22A400)."
-/>
-
-The takeaway from these benchmarks: Turbopack performance is a function of **the size of an update**, not the size of an application.
-
-We're excited by Turbopack's performance, but we also expect to make further speed improvements for both small and large applications in the future. For more info, visit the comparison docs for [Vite](/pack/docs/comparisons/vite) and [webpack](/pack/docs/comparisons/webpack).
-
-#### Data
-
-To run this benchmark yourself, clone [`vercel/turbo`](https://github.com/vercel/turbo) and then use this command from the root:
-
-```
-TURBOPACK_BENCH_COUNTS=1000,5000,10000,30000 TURBOPACK_BENCH_BUNDLERS=all cargo bench -p next-dev "hmr_to_commit/(Turbopack SSR|Next.js 12 SSR|Next.js 11 SSR|Vite SWC CSR)"
-```
-
-Here are the numbers we were able to produce on a 16” MacBook Pro 2021, M1 Max, 32GB RAM, macOS 13.0.1 (22A400):
-
-```sh
-bench_hmr_to_commit/Next.js 11 SSR/1000 modules         211.6±1.14ms
-bench_hmr_to_commit/Next.js 11 SSR/5000 modules        866.0±34.44ms
-bench_hmr_to_commit/Next.js 11 SSR/10000 modules           2.4±0.13s
-bench_hmr_to_commit/Next.js 11 SSR/30000 modules           9.5±3.12s
-bench_hmr_to_commit/Next.js 12 SSR/1000 modules         146.2±2.17ms
-bench_hmr_to_commit/Next.js 12 SSR/5000 modules        494.7±25.13ms
-bench_hmr_to_commit/Next.js 12 SSR/10000 modules     1151.9±280.68ms
-bench_hmr_to_commit/Next.js 12 SSR/30000 modules           6.4±2.29s
-bench_hmr_to_commit/Turbopack SSR/1000 modules           18.9±2.92ms
-bench_hmr_to_commit/Turbopack SSR/5000 modules           23.8±0.31ms
-bench_hmr_to_commit/Turbopack SSR/10000 modules          23.0±0.35ms
-bench_hmr_to_commit/Turbopack SSR/30000 modules          22.5±0.88ms
-bench_hmr_to_commit/Vite SWC CSR/1000 modules           104.8±1.52ms
-bench_hmr_to_commit/Vite SWC CSR/5000 modules           109.6±3.94ms
-bench_hmr_to_commit/Vite SWC CSR/10000 modules          113.0±1.20ms
-bench_hmr_to_commit/Vite SWC CSR/30000 modules         133.3±23.65ms
-```
-
-Note that Vite is using the official [SWC plugin](https://github.com/vitejs/vite-plugin-react-swc) for these benchmarks, which is not the default configuration.
-
-If you have questions about the benchmark, please open an [issue on GitHub](https://github.com/vercel/turbo/issues).
diff --git a/docs/pages/pack/docs/comparisons/BenchmarksCallout.tsx b/docs/pages/pack/docs/comparisons/BenchmarksCallout.tsx
deleted file mode 100644
index 98e33e4..0000000
--- a/docs/pages/pack/docs/comparisons/BenchmarksCallout.tsx
+++ /dev/null
@@ -1,14 +0,0 @@
-import Link from "next/link";
-import Callout from "../../../../components/Callout";
-
-export default function BenchmarksCallout() {
-  return (
-    <Callout type="info">
-      Want to know more about Turbopack&apos;s benchmarking process and
-      philosophy?{" "}
-      <Link href="../benchmarks" className="nx-underline">
-        Learn more about Turbopack&apos;s benchmarking suite.
-      </Link>
-    </Callout>
-  );
-}
diff --git a/docs/pages/pack/docs/comparisons/_meta.json b/docs/pages/pack/docs/comparisons/_meta.json
deleted file mode 100644
index 58ddd9f..0000000
--- a/docs/pages/pack/docs/comparisons/_meta.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
-  "vite": "Vite",
-  "webpack": "Webpack"
-}
diff --git a/docs/pages/pack/docs/comparisons/vite.mdx b/docs/pages/pack/docs/comparisons/vite.mdx
deleted file mode 100644
index 5425796..0000000
--- a/docs/pages/pack/docs/comparisons/vite.mdx
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: Turbopack vs. Vite
-description: Compare Turbopack vs. Vite
----
-
-import { DocsBenchmarksGraph } from '../../../../components/pages/pack-home/DocsBenchmarksGraph';
-import { DocsBenchmarkStat } from '../../../../components/pages/pack-home/DocsBenchmarkStat';
-import BenchmarksCallout from './BenchmarksCallout';
-import Callout from '../../../../components/Callout'
-
-# Comparing Turbopack and Vite
-
-[Vite](https://vitejs.dev/) is an incredibly fast (non-)bundler that the web development community is extremely excited about - and so are we. Vite has raised the bar for web development and shown us what is possible for the future of the Web. If we were going to build a bundler, it had to perform at least as good as the (already impressive) Vite to validate our efforts. We're proud to say that we achieved that.
-
-<BenchmarksCallout />
-
-## Speed
-
-Turbopack can outperform Vite on several key metrics.
-
-### Dev server startup time
-
-Vite is a non-bundler, which means it doesn't bundle your code at all. It sends each module directly to the browser. This means the browser does the hard work of handling dependencies between modules.
-
-On the surface, this seems like an unfair fight. Turbopack _bundles_ your application, meaning that a lot more work needs doing _before_ sending the code to the browser.
-
-But it turns out that Turbopack can handle this _faster_ than the browser can. By pre-bundling, we can save a lot of time over Vite's Native ESM system. You can learn more about this in our [Why Turbopack](/pack/docs/why-turbopack#bundling-vs-native-esm) section.
-
-This means that Turbopack's dev server starts up much faster than Vite's. On a 1,000 module application, Vite takes <DocsBenchmarkStat stat="vite-cold-1000" /> to start up. Turbopack starts up in <DocsBenchmarkStat stat="turbopack-cold-1000" /> - **<DocsBenchmarkStat stat="turbopack-cold-vs-vite" /> faster**.
-
-In large applications, this differential stays consistent. In a 30,000 module application, Turbopack starts up <DocsBenchmarkStat stat="turbopack-cold-vs-vite-30000" /> faster than Vite.
-
-Note that Vite is using the official [SWC plugin](https://github.com/vitejs/vite-plugin-react-swc) for these benchmarks, which is not the default configuration.
-
-<DocsBenchmarksGraph category="cold" bars={[
-  {
-    label: 'Turbopack',
-    turbo: true,
-    key: 'next13'
-  },
-  {
-    label: 'Vite',
-    key: 'vite',
-    swc: true
-  }
-]} />
-
-### Code updates
-
-Vite is extremely fast in development because of its speedy Fast Refresh capabilities. When you update a file, Vite uses its Native ESM system to to send the updated module to the browser - and performs a little bit of magic to integrate that into the existing module graph.
-
-In Turbopack, we discovered that for Fast Refresh, we don't really need to do bundling work at all. We can send updates in a similar style to Vite. In fact - a little bit more efficiently: Turbopack sends changed modules directly through the WebSocket without doing any bundling at all.
-
-In a 1,000 module application, Turbopack can react to file changes **<DocsBenchmarkStat stat="turbopack-update-vs-vite" /> faster** than Vite.
-
-<DocsBenchmarksGraph category="file_change" bars={[
-  {
-    label: 'Turbopack',
-    turbo: true,
-    key: 'next13'
-  },
-  {
-    label: 'Vite',
-    key: 'vite',
-    swc: true
-  }
-]} />
diff --git a/docs/pages/pack/docs/comparisons/webpack.mdx b/docs/pages/pack/docs/comparisons/webpack.mdx
deleted file mode 100644
index a8b821a..0000000
--- a/docs/pages/pack/docs/comparisons/webpack.mdx
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: Turbopack vs. webpack
-description: Compare Turbopack vs. webpack
----
-
-import { DocsBenchmarksGraph } from '../../../../components/pages/pack-home/DocsBenchmarksGraph';
-import { DocsBenchmarkStat } from '../../../../components/pages/pack-home/DocsBenchmarkStat';
-import BenchmarksCallout from './BenchmarksCallout';
-
-# Comparing Turbopack and webpack
-
-webpack has been downloaded over 3 billion times, making it today's most common JavaScript bundler. However, we found that we'd hit the limits of what it could do with its JavaScript-based architecture.
-
-We've built Turbopack as the successor of webpack: much **faster**, but just as **flexible and extensible**.
-
-<BenchmarksCallout />
-
-## Speed
-
-Turbopack's incremental architecture outstrips webpack's speed on several key metrics.
-
-### Dev server startup time
-
-The main problem we found with webpack was development server startup time. If you end up importing a lot of modules in a certain page and open that page in your browser, the initial compile will take a few seconds. If you change routes in your development environment, you have to wait for a similar compile again for your new page.
-
-We designed Turbopack to be as lazy as possible, only doing work when it's requested. In a dev server, this means on incoming requests we do **exactly the work the user asked for**. No more unnecessary bundling of on demand loaded code before the user needs it. You can learn more in our [core concepts docs](/pack/docs/core-concepts#compiling-by-request).
-
-This means that Turbopack's dev server starts up much faster than webpack. Next.js 12, which uses webpack under the hood, can start up a build server on a 1,000 module application in <DocsBenchmarkStat stat="next12-cold-1000" />. Turbopack starts up in <DocsBenchmarkStat stat="turbopack-cold-1000" /> - **<DocsBenchmarkStat stat="turbopack-cold-vs-next12" /> faster**.
-
-<DocsBenchmarksGraph category="cold" bars={[
-  {
-    label: 'Turbopack',
-    turbo: true,
-    key: 'next13'
-  },
-  {
-    label: 'webpack',
-    key: 'next12',
-  }
-]} />
-
-### Code updates
-
-As we continued to optimize webpack, we found a performance ceiling on how much faster we could make Fast Refresh. With around 2,000 components, the best number we could produce was 500ms. This mark was a tremendous feat in Next.js 12. Previously, that process would have taken around 10 seconds.
-
-With Turbopack, we achieved the goal we were aiming for: Fast Refresh performance that stays near-constant, no matter your application size. Instead of scaling with your application size, it scales based on the size of the _changes made_.
-
-In a 1,000 module application, Turbopack can react to file changes **<DocsBenchmarkStat stat="turbopack-update-vs-next12" /> faster** than webpack. In a 30,000 module application, this is **<DocsBenchmarkStat stat="turbopack-update-vs-next12-30000" /> faster**.
-
-<DocsBenchmarksGraph category="file_change" bars={[
-  {
-    label: 'Turbopack',
-    turbo: true,
-    key: 'next13'
-  },
-  {
-    label: 'webpack',
-    key: 'next12',
-  }
-]} />
-
-## Extensibility
-
-webpack has an extraordinary collection of [plugins](https://webpack.js.org/plugins/) to customize its behavior. Composing plugins lets you create custom toolchains which can support a huge variety of bundler features.
-
-In its alpha state, Turbopack cannot currently be configured with plugins. In the future, we plan to make Turbopack just as extensible as webpack - though likely with an altered API.
diff --git a/docs/pages/pack/docs/core-concepts.mdx b/docs/pages/pack/docs/core-concepts.mdx
deleted file mode 100644
index 40e2dd7..0000000
--- a/docs/pages/pack/docs/core-concepts.mdx
+++ /dev/null
@@ -1,64 +0,0 @@
----
-title: Core Concepts
-description: Learn about the innovative architecture that powers Turbopack's speed improvements.
----
-
-# Core Concepts
-
-Let’s dive deep into the internals of Turbopack to figure out why it’s so fast.
-
-## The Turbo engine
-
-Turbopack is so fast because it’s built on a reusable library for Rust which enables incremental computation known as the Turbo engine. Here’s how it works:
-
-### Function-level caching
-
-In a Turbo engine-powered program, you can mark certain functions as ‘to be remembered’. When these functions are called, the Turbo engine will remember **what they were called with**, and **what they returned**. It’ll then save it in an in-memory cache.
-
-Here’s a simplified example of what this might look like in a bundler:
-
-![](/images/docs/pack/turbo-engine-first-run.png)
-
-We start with calling `readFile` on two files, `api.ts` and `sdk.ts`. We then `bundle` those files, `concat` them together, and end up with the `fullBundle` at the end. The results of all of those function calls get saved in the cache for later.
-
-Let’s imagine that we’re running on a dev server. You save the `sdk.ts` file on your machine. Turbopack receives the file system event, and knows it needs to recompute `readFile("sdk.ts")`:
-
-![](/images/docs/pack/turbo-engine-second-run.png)
-
-Since the result of `sdk.ts` has changed, we need to `bundle` it again, which then needs to be concatenated again.
-
-Crucially, `api.ts` hasn’t changed. We read its result from the cache and pass that to `concat` instead. So we save time by not reading it and re-bundling it again.
-
-Now imagine this in a real bundler, with thousands of files to read and transformations to execute. The mental model is the same. You can save enormous amounts of work by remembering the result of function calls and not re-doing work that’s been done before.
-
-### The cache
-
-The Turbo engine currently stores its cache in memory. This means the cache will last as long as the process running it - which works well for a dev server. When you run `next dev --turbo` in Next v13, you’ll start a cache with the Turbo engine. When you cancel your dev server, the cache gets cleared.
-
-In the future, we’re planning to persist this cache - either to the filesystem, or to a remote cache like Turborepo’s. This will mean that Turbopack could remember work done _across runs and machines._
-
-### How does it help?
-
-This approach makes Turbopack extremely fast at computing incremental updates to your apps. This optimizes Turbopack for handling updates in development, meaning your dev server will always respond snappily to changes.
-
-In the future, a persistent cache will open the door to much faster production builds. By remembering work done _across runs_, new production builds could only rebuild changed files - potentially leading to enormous time savings.
-
-## Compiling by Request
-
-The Turbo engine helps provide extremely fast _updates_ on your dev server, but there’s another important metric to consider - startup time. The faster your dev server can start running, the faster you can get to work.
-
-There are two ways to make a process faster - work faster, or do less work. For starting up a dev server, the way to do less work is to compile _only the code that’s needed_ to get started.
-
-### Page-level compilation
-
-Versions of Next.js from 2-3 years ago used to compile the _entire application_ before showing your dev server. In Next.js [11], we began compiling _only the code on the page you requested._
-
-That’s better, but it’s not perfect. When you navigate to `/users`, we’ll bundle all the client and server modules, dynamic-imported modules, and referenced CSS and images. That means if a large part of your page is hidden from view, or hidden behind tabs, we’ll still compile it anyway.
-
-### Request-level compilation
-
-Turbopack is smart enough to compile _only the code you request_. That means if a browser requests HTML, we compile only the HTML - not anything that is referenced by the HTML.
-
-If a browser wants some CSS, we’ll compile only that - without compiling referenced images. Got a big charting library behind `next/dynamic`? Doesn’t compile it until the tab showing the chart is shown. Turbopack even knows _to not compile source maps unless your Chrome DevTools are open_.
-
-If we were to use native ESM, we’d get similar behavior. Except that Native ESM produces a _lot_ of requests to the server, as discussed in our [Why Turbopack](/pack/docs/why-turbopack) section. With request-level compilation, we get to both reduce the number of requests _and_ use native speed to compile them. As you can see in our [benchmarks](/pack/docs/benchmarks), this provides significant performance improvements.
diff --git a/docs/pages/pack/docs/features.mdx b/docs/pages/pack/docs/features.mdx
deleted file mode 100644
index 984bd34..0000000
--- a/docs/pages/pack/docs/features.mdx
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: Features
-description: Learn about Turbopack's supported features
----
-
-import { TurbopackFeatures } from '../../../components/TurbopackFeatures'
-
-# Features
-
-The practice of building web applications is enormously diverse. In CSS alone, you have SCSS, Less, CSS Modules, PostCSS, and hundreds of other libraries. Frameworks like React, Vue and Svelte require custom setups.
-
-When building a bundler, we needed to consider which features would be:
-
-- **Built-in**: they work out of the box, no config required
-- **Available via plugins**: usually installed from a registry and configured
-- **Unavailable**: not available at all
-
-**Turbopack is in alpha**, so very few of these decisions are set in stone. In its current state, **Turbopack cannot yet be configured** - so plugins are not available yet.
-
-Let's discuss which features are available out-of-the-box, in Turbopack's default configuration. We'll also touch on features which will be configurable via plugins.
-
-<TurbopackFeatures />
diff --git a/docs/pages/pack/docs/features/_meta.json b/docs/pages/pack/docs/features/_meta.json
deleted file mode 100644
index c63b5ee..0000000
--- a/docs/pages/pack/docs/features/_meta.json
+++ /dev/null
@@ -1,11 +0,0 @@
-{
-  "javascript": "JavaScript",
-  "typescript": "TypeScript",
-  "frameworks": "Frameworks",
-  "css": "CSS",
-  "dev-server": "Dev Server",
-  "static-assets": "Static Assets",
-  "imports": "Imports",
-  "environment-variables": "Environment Variables",
-  "customizing-turbopack": "Customizing Turbopack"
-}
diff --git a/docs/pages/pack/docs/features/css.mdx b/docs/pages/pack/docs/features/css.mdx
deleted file mode 100644
index 6e2c2fd..0000000
--- a/docs/pages/pack/docs/features/css.mdx
+++ /dev/null
@@ -1,80 +0,0 @@
-import Callout from '../../../../components/Callout';
-
-# CSS
-
-CSS bundling is handled by SWC, using a Rust crate called `swc_css`. We haven't yet documented `swc_css` separately, but it's integrated into Turbopack and supports several CSS features:
-
-## Global CSS
-
-Importing CSS into global scope is supported **out-of-the-box** in Turbopack.
-
-```ts
-import './globals.css';
-```
-
-## CSS Modules
-
-Turbopack handles CSS Modules out-of-the-box. Any file with a `.module.css` extension will be considered a CSS module, and you can import it into a JavaScript or TypeScript file:
-
-```tsx Component.tsx
-import cssExports from './phone.module.css'
-```
-
-This follows the same rules set out by [Next.js](https://nextjs.org/docs/basic-features/built-in-css-support#adding-component-level-css) - letting you easily distinguish between global and scoped CSS.
-
-## `postcss-nested`
-
-Turbopack handles [`postcss-nested`](https://www.npmjs.com/package/postcss-nested) syntax out-of-the-box. This useful library lets you nest CSS declarations inside each other:
-
-```css phone.css
-.phone {
-    &_title {
-        width: 500px;
-        @media (max-width: 500px) {
-            width: auto;
-        }
-        body.is_dark & {
-            color: white;
-        }
-    }
-    img {
-        display: block;
-    }
-}
-```
-
-## `@import` syntax
-
-Using the CSS `@import` syntax to import other CSS files works **out-of-the-box**. This gives you the ability to combine several CSS files together into a single module:
-
-```css filename="globals.css"
-@import './modal.css';
-@import './dark.css';
-```
-
-## PostCSS
-
-PostCSS gives you the ability to use plugins to enhance your CSS toolchain. It's been an invaluable tool for integrating libraries like Tailwind and `autoprefixer` into applications.
-
-The most common pattern is adding a `postcss.config.js` file to the root of your application, where you can import and configure your plugins.
-
-When Turbopack finds a `postcss.config.js` file, it will automatically process your CSS files with PostCSS in a Node.js worker pool.
-
-```js filename="postcss.config.js"
-module.exports = {
-  plugins: {
-    tailwindcss: {},
-    autoprefixer: {}
-  }
-};
-```
-
-## SCSS and LESS
-
-`.scss` and `.less` files let you utilize SCSS and LESS - languages which enhance CSS in various ways. These languages **don't currently work** out-of-the-box with Turbopack.
-
-These are likely to be available via plugins in the future.
-
-## Tailwind CSS
-
-Tailwind CSS can be used via PostCSS plugins. You can use the [official Tailwind Next.js guide](https://tailwindcss.com/docs/guides/nextjs) to get started.
diff --git a/docs/pages/pack/docs/features/customizing-turbopack.mdx b/docs/pages/pack/docs/features/customizing-turbopack.mdx
deleted file mode 100644
index 2ddd6a1..0000000
--- a/docs/pages/pack/docs/features/customizing-turbopack.mdx
+++ /dev/null
@@ -1,112 +0,0 @@
----
-title: Customizing Turbopack
-description: Learn about how to customize Turbopack to your needs
----
-
-import Callout from "../../../../components/Callout";
-
-# Customizing Turbopack
-
-Turbopack can be customized to transform different files and change how modules are resolved. It supports a subset of webpack's loader API and offers similar configuration aliasing module resolution.
-
-## webpack loaders for Next.js
-
-<Callout type="info">
-  Turbopack for Next.js does not require loaders nor loader configuration for built-in functionality, just as they aren't required for Next.js. Turbopack has built-in support for css and compiling modern JavaScript, so there's no need for `css-loader`, `postcss-loader`, or `babel-loader` if you're just using `@babel/preset-env`.
-</Callout>
-
-If you need loader support beyond what's built in, many webpack loaders already work with Turbopack. There are currently some limitations:
-
-- Only a core subset of the webpack loader API is implemented. This is enough for some popular loaders, and we'll expand our support for this API in the future.
-- Only loaders that return JavaScript code are supported. Loaders that transform files like stylesheets or images are not currently supported.
-- Options passed to webpack loaders must be plain JavaScript primitives, objects, and arrays. For example, it's not possible to pass `require()`d plugin modules as option values.
-
-As of Next 13.2, configuring webpack loaders is possible for Next.js apps through an experimental option in `next.config.js`. `turbo.loaders` can be set as a mapping of file extensions to a list of package names or `{loader, options}` pairs:
-
-```js filename="next.config.js"
-module.exports = {
-  experimental: {
-    turbo: {
-      loaders: {
-        // Option format
-        '.md': [
-          {
-            loader: '@mdx-js/loader',
-            options: {
-              format: 'md',
-            },
-          },
-        ],
-        // Option-less format
-        '.mdx': ['@mdx-js/loader'],
-      },
-    },
-  },
-}
-```
-
-If you need to pass something like the result of importing an external package as a loader option, it's possible to wrap the webpack loader with your own, specifying options there. **This is an interim solution and should not be necessary in the future.** This loader wraps `@mdx-js/loader` and configures the `rehypePrism` rehype plugin:
-
-```js filename="my-mdx-loader.js"
-const mdxLoader = require('@mdx-js/loader');
-const rehypePrism = require('@mapbox/rehype-prism');
-
-module.exports = function (code) {
-	const prevGetOptions = this.getOptions.bind(this);
-	this.getOptions = function getOptions(...args) {
-		return {
-			...prevGetOptions(...args),
-			rehypePlugins: [rehypePrism]
-		}
-	}
-
-	mdxLoader.call(this, code);
-}
-```
-
-Then, configure Next.js to load the wrapper loader:
-
-```js filename="next.config.js"
-module.exports = {
-  experimental: {
-    turbo: {
-      loaders: {
-        '.mdx': ['./my-mdx-loader'],
-      },
-    },
-  },
-}
-```
-
-### Supported loaders
-
-The following loaders have been tested to work with Turbopack's webpack loader implementation:
-
-- [`babel-loader`](https://www.npmjs.com/package/babel-loader)
-- [`@mdx-js/loader`](https://www.npmjs.com/package/@mdx-js/loader)
-- [`@svgr/webpack`](https://www.npmjs.com/package/@svgr/webpack)
-- [`svg-inline-loader`](https://www.npmjs.com/package/svg-inline-loader)
-- [`yaml-loader`](https://www.npmjs.com/package/yaml-loader)
-- [`string-replace-loader`](https://www.npmjs.com/package/string-replace-loader)
-- [`raw-loader`](https://www.npmjs.com/package/raw-loader)
-
-## Resolve aliases
-
-Turbopack can be configured to modify module resolution through aliases, similar to webpack's [`resolve.alias`](https://webpack.js.org/configuration/resolve/#resolvealias) configuration:
-
-```js filename="next.config.js"
-module.exports = {
-  experimental: {
-    turbo: {
-      resolveAlias: {
-        underscore: 'lodash',
-        mocha: { browser: 'mocha/browser-entry.js' },
-      },
-    },
-  },
-}
-```
-
-This aliases imports of the `underscore` package to the `lodash` package. In other words, `import underscore from 'underscore'` will load the `lodash` module instead of `underscore`.
-
-Turbopack also supports conditional aliasing through this field, similar to Node.js's [conditional exports](https://nodejs.org/docs/latest-v18.x/api/packages.html#conditional-exports). At the moment only the `browser` condition is supported. In the case above, imports of the `mocha` module will be aliased to `mocha/browser-entry.js` when Turbopack targets browser environments.
diff --git a/docs/pages/pack/docs/features/dev-server.mdx b/docs/pages/pack/docs/features/dev-server.mdx
deleted file mode 100644
index ef8e01a..0000000
--- a/docs/pages/pack/docs/features/dev-server.mdx
+++ /dev/null
@@ -1,17 +0,0 @@
-# Dev Server
-
-Turbopack is optimized to give you an extremely fast development server. We considered these features indispensable.
-
-## HMR
-
-Hot Module Replacement (HMR) gives your dev server the ability to push file updates to the browser without triggering a full refresh. This works for most static assets (including JavaScript files) enabling a smooth and fast developer experience.
-
-Turbopack supports Hot Module Replacement out of the box. Because of our [incremental architecture](/pack/docs/core-concepts), we are hyper-optimized for delivering fast updates.
-
-{/* Maybe link to benchmarks here? */}
-
-## Fast Refresh
-
-Fast Refresh builds on top of HMR by providing a framework-level integration to preserve _state_ across updates. Changes to a `<Count />` component, for instance, would preserve the component's internal `count` across changes.
-
-Turbopack supports Fast Refresh out of the box for React. Support for other frameworks will be [added over time](/pack/docs/features/frameworks).
diff --git a/docs/pages/pack/docs/features/environment-variables.mdx b/docs/pages/pack/docs/features/environment-variables.mdx
deleted file mode 100644
index 4e6daec..0000000
--- a/docs/pages/pack/docs/features/environment-variables.mdx
+++ /dev/null
@@ -1,29 +0,0 @@
-# Environment variables
-
-## `.env` files
-
-Turbopack will parse and inject `.env` files out of the box.
-
-```
-NEXT_PUBLIC_DEPLOYMENT_NAME="my-site"
-DATABASE_URL="postgres://"
-```
-
-This includes all the variations these files come in:
-
-```
-.env
-.env.local
-.env.development
-.env.production.local
-```
-
-### Live reloading
-
-Not only that, but Turbopack will live reload when these values change. Restarting your dev server just to inject a new environment variable can be extremely annoying - Turbopack does it for you.
-
-## `process.env`
-
-Environment variables will be injected into `process.env`. For instance, `DATABASE_URL` will be on `process.env.DATABASE_URL`.
-
-This follows the tradition of Node.js, webpack 5 and Next.js 12, which each use `process.env` for variable injection.
diff --git a/docs/pages/pack/docs/features/frameworks.mdx b/docs/pages/pack/docs/features/frameworks.mdx
deleted file mode 100644
index 59f6998..0000000
--- a/docs/pages/pack/docs/features/frameworks.mdx
+++ /dev/null
@@ -1,45 +0,0 @@
-# Frameworks
-
-Turbopack plans to offer first-class support for multiple frameworks. No matter whether you're using Svelte, React, Vue.js, or another framework, we want to provide a great experience on Turbopack.
-
-## React
-
-### JSX/TSX
-
-`.jsx` and `.tsx` files are supported out of the box with Turbopack. We use [SWC](https://swc.rs/) to compile your JavaScript and TypeScript code, which results in extremely fast compilation.
-
-Similar to Next.js, Turbopack doesn't require you to import React in order to use JSX:
-
-```diff filename="src/index.tsx"
-- import React from 'react';
-
-const Component = () => {
-  return <div />
-}
-```
-
-### React Server Components
-
-React Server Components let you declare certain components as 'server' components, allowing you to run backend code inside an `async` function. Next.js 13 brings [first-class support for them](https://beta.nextjs.org/docs/rendering/server-and-client-components).
-
-React Server Components impose unusual constraints on your bundler. The mix of client and server code means you need to ensure that server code does not get compiled to the client, and vice versa.
-
-Turbopack has been built from the ground up to solve these problems - it works with React Server Components out of the box.
-
-## Next
-
-Turbopack's Alpha version has been focused on providing a great experience for Next.js's dev server. We're using this as our initial goal to show what Turbopack can do. In the future, we want Turbopack to act as a low-level engine for other frameworks.
-
-This means that Turbopack plans to support everything in Next.js.
-
-### `next/dynamic`
-
-[`next/dynamic`](https://nextjs.org/docs/advanced-features/dynamic-import) is not yet supported - however, we plan to support it out of the box soon.
-
-## Vue and Svelte
-
-[VueJS](https://vuejs.org/) and [Svelte](https://svelte.dev/) are tremendously popular frameworks which deliver a world-class developer experience.
-
-Since Turbopack is in alpha, we're focusing our support on Next.js's dev server. That means that right now, Vue and Svelte don't work out of the box.
-
-In future versions, we'll be supporting Vue and Svelte via plugins.
diff --git a/docs/pages/pack/docs/features/imports.mdx b/docs/pages/pack/docs/features/imports.mdx
deleted file mode 100644
index 5dee4ce..0000000
--- a/docs/pages/pack/docs/features/imports.mdx
+++ /dev/null
@@ -1,47 +0,0 @@
-# Imports
-
-Turbopack supports CJS and ESM imports out of the box, and offers partial support for AMD.
-
-Turbopack bundles your application, so imports won't be resolved to native browser ESM. You can learn why in our [bundling vs Native ESM](/pack/docs/why-turbopack#bundling-vs-native-esm) section.
-
-## CommonJS
-
-Turbopack supports the `require` syntax out-of-the-box:
-
-```ts
-const { add } = require('./math');
-
-add(1, 2);
-```
-
-We also support dynamic `require()` syntax, for if you want to import a dynamically named asset:
-
-```ts
-const imgName = getRandomImgName();
-
-const img = require(`./images/${imgName}.png`);
-```
-
-## ESM
-
-Importing via the `import` syntax is also supported out-of-the-box. This includes static assets, and `import type`:
-
-```ts
-import img from './img.png';
-
-import type { User } from '../server/types';
-
-import { z } from 'zod';
-```
-
-## Dynamic Imports
-
-Turbopack supports dynamic imports via `import()`:
-
-```ts
-const getFeatureFlags = () => {
-  return import('/featureFlags').then(mod => {
-    return mod.featureFlags;
-  })
-}
-```
diff --git a/docs/pages/pack/docs/features/javascript.mdx b/docs/pages/pack/docs/features/javascript.mdx
deleted file mode 100644
index 8b7a294..0000000
--- a/docs/pages/pack/docs/features/javascript.mdx
+++ /dev/null
@@ -1,39 +0,0 @@
-import Callout from "../../../../components/Callout";
-
-# JavaScript
-
-## ECMAScript Support
-
-Turbopack uses [SWC](https://swc.rs/) to bundle JavaScript and TypeScript files. So, we match SWC's support for ECMAScript versions - anything that SWC supports, Turbopack will support.
-
-This means that by default **we support all syntax in ESNext**.
-
-## Browserslist
-
-[Browserslist](https://github.com/browserslist/browserslist) has become an industry standard for defining which browsers you plan to target. To make use of it, you can add a `browserslist` field to your `package.json`:
-
-```json filename="package.json"
-{
-  "browserslist": [
-    "last 1 version",
-    "> 1%",
-    "not dead"
-  ]
-}
-```
-
-Turbopack supports Browserslist **out-of-the-box**. We pass the information we find in your `package.json` to SWC, which handles [`browserslist` support](https://swc.rs/docs/configuration/supported-browsers) for us.
-
-This means you can feel comfortable using Turbopack to target legacy browsers, or deciding to only ship code to modern browsers.
-
-<Callout type="info">
-  Turbopack is available in alpha preview with a dev server, which uses a pre-set minimal browserslist to minimize transformation during development. In a future release, Turbopack will build apps for production targeting your defined browserslist.
-</Callout>
-
-## Babel
-
-[Babel](https://babel.dev/) allows you to add custom transformations to your code to provide custom syntax, including support for early language proposals.
-
-Babel plugins are currently **not supported** on Turbopack. In our default configuration, we don't use Babel to compile JavaScript or TypeScript code.
-
-In the future, Babel support will be provided via plugins.
diff --git a/docs/pages/pack/docs/features/static-assets.mdx b/docs/pages/pack/docs/features/static-assets.mdx
deleted file mode 100644
index 26ebf7a..0000000
--- a/docs/pages/pack/docs/features/static-assets.mdx
+++ /dev/null
@@ -1,47 +0,0 @@
-# Static Assets
-
-Part of bundling for the web is handling all the asset types the web supports - images, videos, JSON, fonts, and much more. Turbopack offers familiar tools for these so you can immediately get productive.
-
-## Import static assets
-
-Importing static assets works out of the box with Turbopack:
-
-```ts
-import img from './img.png'
-import video from './video.mp4'
-import audio from './audio.wav'
-```
-
-### Next.js
-
-In webpack and some other frameworks, importing an image returns a string containing that image's URL.
-
-```ts
-import img from './img.png';
-
-console.log(img); // /assets/static/1uahwd98h123.png
-```
-
-In Next.js, importing an image actually returns an object, containing various metadata about the image. This is so it can be fed into [Next.js's Image component](https://nextjs.org/docs/basic-features/image-optimization#local-images).
-
-The behavior of extracting an object of metadata from the image is **not yet supported**. For now, imported images will resolve to strings.
-
-## Public directory
-
-The `/public` directory lets you place assets which you want to be available on the root URL of the website. For instance, `public/favicon.png` will be available at `https://example/favicon.png`.
-
-In Turbopack, the `/public` directory is supported out of the box.
-
-## JSON
-
-Most frameworks allow you to import JSON directly into your application:
-
-```ts
-import fixtures from './fixtures.json';
-```
-
-This is supported out of the box with Turbopack, as is performing a named import on that JSON:
-
-```ts
-import { users, posts } from './fixtures.json';
-```
diff --git a/docs/pages/pack/docs/features/typescript.mdx b/docs/pages/pack/docs/features/typescript.mdx
deleted file mode 100644
index a643486..0000000
--- a/docs/pages/pack/docs/features/typescript.mdx
+++ /dev/null
@@ -1,40 +0,0 @@
-# TypeScript
-
-Turbopack supports [TypeScript](https://www.typescriptlang.org/) out of the box. This means you can import `.ts` files with Turbopack. We support all of TypeScript's feature set.
-
-Thanks to our JSX support, you can also import `.tsx` files too.
-
-## Resolving `paths` and `baseUrl`
-
-In TypeScript, you can use the [`paths`](https://www.typescriptlang.org/tsconfig#paths) property of `tsconfig.json` to let you import files from custom paths.
-
-```json
-{
-  "compilerOptions": {
-    "baseUrl": "src",
-    "paths": {
-        "app/*": ["app/*"],
-        "config/*": ["app/_config/*"],
-        "shared/*": ["app/_shared/*"],
-    },
-}
-```
-
-This would let you import directly from `app/*` without needing to do a relative import:
-
-```diff filename="src/app/some/deep/file/in/your/app.ts"
-- import { add } from '../../../../../math';
-+ import { add } from 'app/math';
-
-add();
-```
-
-Turbopack reads the `paths` and `baseUrl` in `tsconfig.json` in order to resolve these paths, just like `Next.js` does.
-
-This means you only need to configure your absolute paths in one place.
-
-## Type Checking
-
-Turbopack does not perform type checks on your application. We use [SWC](https://swc.rs/) to compile TypeScript code, which also does not perform type checks.
-
-This means that in order to run your type checks, you'll need a sidecar process running `tsc --watch`. Or, you can rely on your IDE's TypeScript integration.
diff --git a/docs/pages/pack/docs/index.mdx b/docs/pages/pack/docs/index.mdx
deleted file mode 100644
index 3cbc782..0000000
--- a/docs/pages/pack/docs/index.mdx
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: Turbopack Quickstart
-description: Start Building Web Applications with Turbopack
----
-
-import { TurbopackQuickstartArea } from "../../../components/TurbopackQuickstart";
-import Callout  from "../../../components/Callout";
-import { Tabs, Tab } from "../../../components/Tabs";
-import FullTurboCTA from "../../../components/FullTurboCTA";
-
-# Getting Started with Turbopack
-
-Turbopack is an incremental bundler optimized for JavaScript and TypeScript, written in Rust by the creators of webpack and [Next.js](https://nextjs.org/) at [Vercel](https://vercel.com/).
-
-The secret to Turbopack's performance is twofold: highly optimized machine code and a low-level incremental computation engine that enables caching down to the level of individual functions. Once Turbopack performs a task it never does it again.
-
-Our team has taken the lessons from 10 years of webpack, combined with the innovations in incremental computation from [Turborepo](/repo) and Google's Bazel, and created an architecture ready to support the coming decades of computing.
-
-<Callout type="error">
-    Turbopack is currently in <strong>alpha</strong>. It is not yet ready for production use. We appreciate your support and feedback as we work to make it ready for everyone.
-</Callout>
-
-## Quickstart
-
-As of today, Turbopack can be used in Next.js v13. In the future we will be releasing a standalone CLI, plugin API, and support for other frameworks such as Svelte and Vue. For now, please follow these instructions to get started:
-
-1. Create a Next.js v13 project with Turbopack:
-
-```bash
-npx create-next-app --example with-turbopack
-```
-
-2. Start the Next.js development server (with Turbopack):
-
-  <Tabs items={["npm", "yarn", "pnpm"]} storageKey="selected-pkg-manager">
-    <Tab>
-      ```bash
-      npm run dev
-      ```
-    </Tab>
-    <Tab>
-      ```bash
-      yarn dev
-      ```
-    </Tab>
-    <Tab>
-      ```bash
-      pnpm dev
-      ```
-    </Tab>
-  </Tabs>
-
-The Next.js v13 development server is now powered by Turbopack! Startup and updates should both be near-instant. The larger the application, the larger the improvement will be.
-
-## Next Steps
-
-Want to learn more about Turbopack? Here's a deep dive on what we think makes it special.
-
-<TurbopackQuickstartArea />
-
-<FullTurboCTA />
diff --git a/docs/pages/pack/docs/migrating-from-webpack.mdx b/docs/pages/pack/docs/migrating-from-webpack.mdx
deleted file mode 100644
index 1788b18..0000000
--- a/docs/pages/pack/docs/migrating-from-webpack.mdx
+++ /dev/null
@@ -1,34 +0,0 @@
----
-title: Migrate from webpack to Turbopack
-description: Learn about how to migrate from webpack to its Rust-powered successor, Turbopack.
----
-
-import Callout from "../../../components/Callout";
-
-# Migrating from webpack to Turbopack
-
-<Callout type="info">
-  Turbopack now implements basic webpack loader support and configuration familiar to webpack users. Visit [Customizing Turbopack](features/customizing-turbopack) for how to configure Turbopack to use webpack loaders.
-</Callout>
-
-We're planning Turbopack as the successor to webpack. In the future, we plan to give Turbopack all the tools needed to support your webpack app.
-
-## webpack loaders and resolve aliases
-
-For apps running Next.js 13.2 or later, Turbopack supports configuration familiar to webpack users, including support for webpack loaders and customizing resolution rules. Visit [Customizing Turbopack](features/customizing-turbopack) for how to configure Turbopack with these options. Note that using webpack-based Next.js plugins as-is from `next.config.js` is **not yet possible**.
-
-## FAQ
-
-### Will it be compatible with webpack's API?
-
-webpack has a huge API. It's extremely flexible and extensible, which is a big reason why it's so popular.
-
-We're planning on making Turbopack very flexible and extensible, but we're **not planning 1:1 compatibility with webpack**. This lets us make choices which improve on webpack's API, and lets us optimize for speed and efficiency.
-
-### Will we be able to use webpack plugins?
-
-webpack plugins are a crucial part of webpack's ecosystem. They let you customize your toolchain, giving you low-level tools to maximize your productivity.
-
-Unlike loaders, webpack plugins can be tightly integrated with webpack's internals.
-
-Since we're not offering 1:1 API compatibility for plugins, most won't work out of the box with Turbopack. However, we're working on porting several of the most popular webpack plugins to Turbopack.
diff --git a/docs/pages/pack/docs/roadmap.mdx b/docs/pages/pack/docs/roadmap.mdx
deleted file mode 100644
index 9bd7c97..0000000
--- a/docs/pages/pack/docs/roadmap.mdx
+++ /dev/null
@@ -1,33 +0,0 @@
-# Roadmap
-
-We've got big plans for Turbopack. Here's what we're aiming for in the future:
-
-## Next.js
-
-Right now, Turbopack is being used as an opt-in feature in Next.js's dev server. This is helping to create an extremely fast experience in local development that scales to big projects.
-
-Next, we want to use Turbopack to power production builds with Next.js. We think that this will result in a big boost in performance, especially when integrated with remote caching.
-
-## Svelte
-
-We're planning to build a first-class integration with Svelte to let Turbopack power the next generation of SvelteKit applications.
-
-## Other Frameworks
-
-We are in active discussions with other frameworks to bring Turbopack to their users. We're excited to see what we can build together!
-
-## Remote Caching and Replication
-
-Turbopack is built from the ground up to take advantage of [caching](/pack/docs/core-concepts#the-turbo-engine). Currently, this cache is stored in-memory only. This lets us optimize for our current use case - making the Next.js dev server fast.
-
-In the future, we plan to persist this cache to the file system, to speed up Turbopack between runs. This will work similarly to [Turborepo's cache](/repo/docs/core-concepts/caching) - but at a much more granular level. Turborepo can currently only cache the results of entire builds. Turbopack, however, can cache the results of individual functions within those builds - saving much more time over subsequent runs.
-
-Once persisting to the file system is working, we can build the next logical step: persisting to a remote cache. With Turborepo, we've already built [remote caching](/repo/docs/core-concepts/remote-caching) on Vercel. In the future, you'll be able to _share_ Turbopack's hyper-granular cache across your whole team, using the Vercel Remote Cache.
-
-## Migration for webpack users
-
-To learn more about our future plans for webpack integration, check out our [Migrating from webpack](/pack/docs/migrating-from-webpack) page.
-
-## Fusion with Turborepo
-
-We are currently migrating/rewriting Turborepo in Rust. In the future, Turborepo and Turbopack will merge into a single toolchain--Turbo--that can be used as either a bundler or a build system or both.
diff --git a/docs/pages/pack/docs/why-turbopack.mdx b/docs/pages/pack/docs/why-turbopack.mdx
deleted file mode 100644
index 18cec98..0000000
--- a/docs/pages/pack/docs/why-turbopack.mdx
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: Why Turbopack?
-description: Learn why we think Turbopack is the future of bundling for the web.
----
-
-# Why Turbopack?
-
-When we set out to create Turbopack, we wanted to solve a problem. We had been working on speed improvements for Next.js. We migrated away from several JS-based tools. Babel, gone. Terser, gone. Our next target was another JS-based tool, webpack.
-
-Replacing it became our goal. But with what?
-
-A new generation of native-speed bundlers were emerging, like esbuild and swc. But after assessing the bundlers on the market, we decided to build our own. Why?
-
-## Bundling vs Native ESM
-
-Frameworks like Vite use a technique where they don’t bundle application source code in development mode. Instead, they rely on the browser’s native ES Modules system. This approach results in incredibly responsive updates since they only have to transform a single file.
-
-However, Vite can hit scaling issues with large applications made up of many modules. A flood of cascading network requests in the browser can lead to a relatively slow startup time. For the browser, it’s faster if it can receive the code it needs in as few network requests as possible - even on a local server.
-
-That’s why we decided that, like webpack, we wanted Turbopack to bundle the code in the development server. Turbopack can do it much faster, especially for larger applications, because it is written in Rust and skips optimization work that is only necessary for production.
-
-## Incremental Computation
-
-There are two ways to make a process faster: do less work or do work in parallel. We knew if we wanted to make the fastest bundler possible, we’d need to pull hard on both levers.
-
-We decided to create a reusable Turbo build engine for distributed and incremental behavior. The Turbo engine works like a scheduler for function calls, allowing calls to functions to be parallelized across all available cores.
-
-The Turbo engine also caches the result of all the functions it schedules, meaning it never needs to do the same work twice. Put simply, **it does the minimum work at maximum speed**.
-
-### Vite and esbuild
-
-Other tools take a different attitude to ‘doing less work’. Vite minimizes work done by using Native ESM in development mode. We decided not to take this approach for the reasons listed above.
-
-Under the hood, Vite uses esbuild for many tasks. esbuild is a bundler - a superbly fast one. It doesn’t force you to use native ESM. But we decided not to adopt esbuild for a few reasons.
-
-esbuild’s code is hyper-optimized for one task - bundling fast. It doesn’t have HMR, which we don’t want to lose from our dev server.
-
-esbuild is an extremely fast bundler, but it doesn’t do much caching. This means you _will_ end up doing the same work again and again, even if that work is at the speed of native.
-
-Evan Wallace refers to esbuild as a [proof-of-concept for the next generation of bundlers](https://news.ycombinator.com/item?id=22336334). We think he’s right. We feel that a Rust-powered bundler _with_ incremental computation could perform better at a larger scale than esbuild.
-
-## Lazy bundling
-
-Early versions of Next.js tried to bundle the _entire_ web app in development mode. We quickly realized that this ‘eager’ approach was less than optimal. Modern versions of Next.js bundle only the pages requested by the dev server. For instance, if you go to `localhost:3000`, it’ll bundle only `pages/index.jsx`, and the modules it imports.
-
-This more ‘lazy’ approach (only bundling assets when absolutely necessary) is key for a fast dev server. Native ESM handles this without much magic - you request a module, which requests other modules. However, we wanted to build a bundler, for the reasons explained above.
-
-esbuild doesn’t have a concept of ‘lazy’ bundling - it’s all-or-nothing, unless you specifically target only certain entry points.
-
-Turbopack’s development mode builds a minimal graph of your app’s imports and exports based on received requests and only bundles the minimal code necessary. Learn more in the [core concepts docs](/pack/docs/core-concepts#compiling-by-request).
-
-This strategy makes Turbopack extremely fast when first starting up the dev server. We compute only the code necessary to render the page, then ship it to the browser in a single chunk. At large scale, this ends up being significantly faster than Native ESM.
-
-## Summary
-
-We wanted to:
-
-- Build a bundler. Bundlers outperform Native ESM when working on large applications.
-- Use incremental computation. The Turbo engine brings this into the core of Turbopack’s architecture - maximizing speed and minimizing work done.
-- Optimize our dev server’s startup time. For that, we build a lazy asset graph to compute only the assets requested.
-
-That’s why we chose to build Turbopack.
diff --git a/docs/pages/pack/index.mdx b/docs/pages/pack/index.mdx
deleted file mode 100644
index f1f71b1..0000000
--- a/docs/pages/pack/index.mdx
+++ /dev/null
@@ -1,8 +0,0 @@
----
-overrideTitle: "Turbopack - The successor to webpack"
-description: "Turbopack is an incremental bundler optimized for JavaScript and TypeScript, written in Rust."
----
-
-import TurbopackHome from "../../components/pages/pack-home";
-
-<TurbopackHome />