bun-types 1.3.3-canary.20251109T140619 → 1.3.3-canary.20251111T140653

package/docs/guides/deployment/vercel.mdx

@@ -32,7 +32,7 @@ import { ProductCard } from "/snippets/product-card.mdx";
 
     	Vercel automatically detects this configuration and runs your application on Bun. The value has to be `"1.x"`, Vercel handles the minor version internally.
 
-    	For best results, match your local Bun version with the version used by Vercel. **Currently, Bun version `1.2.23` is supported**.
+    	For best results, match your local Bun version with the version used by Vercel.
     </Step>
 
     <Step title="Next.js configuration">
@@ -81,7 +81,7 @@ import { ProductCard } from "/snippets/product-card.mdx";
     	console.log("runtime", process.versions.bun);
     	```
     	```txt
-    	runtime 1.2.23
+    	runtime 1.3.2
     	```
 
     	[See the Vercel Bun Runtime documentation for feature support →](https://vercel.com/docs/functions/runtimes/bun#feature-support)

package/docs/guides/ecosystem/tanstack-start.mdx

@@ -0,0 +1,154 @@
+---
+title: Use TanStack Start with Bun
+sidebarTitle: TanStack Start with Bun
+mode: center
+---
+
+[TanStack Start](https://tanstack.com/start/latest) is a full-stack framework powered by TanStack Router. It supports full-document SSR, streaming, server functions, bundling and more, powered by TanStack Router and [Vite](https://vite.dev/).
+
+---
+
+<Steps>
+  <Step title="Create a new TanStack Start app">
+    Use the interactive CLI to create a new TanStack Start app.
+
+    ```sh terminal icon="terminal"
+    bun create @tanstack/start@latest my-tanstack-app
+    ```
+
+  </Step>
+  <Step title="Start the dev server">
+    Change to the project directory and run the dev server with Bun.
+
+    ```sh terminal icon="terminal"
+    cd my-tanstack-app
+    bun --bun run dev
+    ```
+
+    This starts the Vite dev server with Bun.
+
+  </Step>
+  <Step title="Update scripts in package.json">
+   Modify the scripts field in your `package.json` by prefixing the Vite CLI commands with `bun --bun`. This ensures that Bun executes the Vite CLI for common tasks like `dev`, `build`, and `preview`.
+
+    ```json package.json icon="file-json"
+    {
+      "scripts": {
+        "dev": "bun --bun vite dev", // [!code ++]
+        "build": "bun --bun vite build", // [!code ++]
+        "serve": "bun --bun vite preview" // [!code ++]
+      }
+    }
+    ```
+
+  </Step>
+</Steps>
+
+---
+
+## Hosting
+
+<Steps>
+  <Step title="Add Nitro to your project">
+    Add [Nitro](https://nitro.build/) to your project. This tool allows you to deploy your TanStack Start app to different platforms.
+
+    ```sh terminal icon="terminal"
+    bun add nitro
+    ```
+
+  </Step>
+  <Step title={<span>Update your <code>vite.config.ts</code> file</span>}>
+    Update your `vite.config.ts` file to include the necessary plugins for TanStack Start with Bun.
+
+    ```ts vite.config.ts icon="/icons/typescript.svg"
+    // other imports...
+    import { nitro } from "nitro/vite"; // [!code ++]
+
+    const config = defineConfig({
+      plugins: [
+        tanstackStart(),
+        nitro({ preset: "bun" }), // [!code ++]
+        // other plugins...
+      ],
+    });
+
+    export default config;
+    ```
+
+    <Note>
+      The `bun` preset is optional, but it configures the build output specifically for Bun's runtime.
+    </Note>
+
+  </Step>
+  <Step title="Update the start command">
+    Make sure `build` and `start` scripts are present in your `package.json` file:
+
+    ```json package.json icon="file-json"
+      {
+        "scripts": {
+          "build": "bun --bun vite build", // [!code ++]
+          // The .output files are created by Nitro when you run `bun run build`.
+          // Not necessary when deploying to Vercel.
+          "start": "bun run .output/server/index.mjs" // [!code ++]
+        }
+      }
+    ```
+
+
+    <Note>
+      You do **not** need the custom `start` script when deploying to Vercel.
+    </Note>
+
+  </Step>
+  <Step title="Deploy your app">
+    Check out one of our guides to deploy your app to a hosting provider.
+
+    <Note>
+      When deploying to Vercel, you can either add the `"bunVersion": "1.x"` to your `vercel.json` file, or add it to the `nitro` config in your `vite.config.ts` file:
+
+      <Warning>
+        Do **not** use the `bun` Nitro preset when deploying to Vercel.
+      </Warning>
+
+      ```ts vite.config.ts icon="/icons/typescript.svg"
+      export default defineConfig({
+        plugins: [
+          tanstackStart(),
+          nitro({
+            preset: "bun", // [!code --]
+            vercel: { // [!code ++]
+              functions: { // [!code ++]
+                runtime: "bun1.x", // [!code ++]
+              }, // [!code ++]
+            }, // [!code ++]
+          }),
+        ],
+      });
+      ```
+    </Note>
+
+    <Columns cols={3}>
+      <Card title="Vercel" href="/guides/deployment/vercel" icon="/icons/ecosystem/vercel.svg">
+        Deploy on Vercel
+      </Card>
+      <Card title="Render" href="/guides/deployment/render" icon="/icons/ecosystem/render.svg">
+        Deploy on Render
+      </Card>
+      <Card title="Railway" href="/guides/deployment/railway" icon="/icons/ecosystem/railway.svg">
+        Deploy on Railway
+      </Card>
+       <Card title="DigitalOcean" href="/guides/deployment/digital-ocean" icon="/icons/ecosystem/digitalocean.svg">
+        Deploy on DigitalOcean
+      </Card>
+      <Card title="AWS Lambda" href="/guides/deployment/aws-lambda" icon="/icons/ecosystem/aws.svg">
+        Deploy on AWS Lambda
+      </Card>
+      <Card title="Google Cloud Run" href="/guides/deployment/google-cloud-run" icon="/icons/ecosystem/gcp.svg">
+        Deploy on Google Cloud Run
+      </Card>
+    </Columns>
+
+  </Step>
+</Steps>
+
+[→ See TanStack Start's official documentation](https://tanstack.com/start/latest/docs/framework/react/guide/hosting) for more information on hosting.

package/docs/guides/install/add-git.mdx

@@ -33,6 +33,8 @@ bun add git@github.com:lodash/lodash.git
 bun add github:colinhacks/zod
 ```
 
+**Note:** GitHub dependencies download via HTTP tarball when possible for faster installation.
+
 ---
 
 See [Docs > Package manager](https://bun.com/docs/cli/install) for complete documentation of Bun's package manager.

package/docs/pm/cli/install.mdx

@@ -88,6 +88,13 @@ Lifecycle scripts will run in parallel during installation. To adjust the maximu
 bun install --concurrent-scripts 5
 ```
 
+Bun automatically optimizes postinstall scripts for popular packages (like `esbuild`, `sharp`, etc.) by determining which scripts need to run. To disable these optimizations:
+
+```bash terminal icon="terminal"
+BUN_FEATURE_FLAG_DISABLE_NATIVE_DEPENDENCY_LINKER=1 bun install
+BUN_FEATURE_FLAG_DISABLE_IGNORE_SCRIPTS=1 bun install
+```
+
 ---
 
 ## Workspaces
@@ -231,7 +238,7 @@ Bun supports installing dependencies from Git, GitHub, and local or remotely-hos
 
 Bun supports two package installation strategies that determine how dependencies are organized in `node_modules`:
 
-### Hoisted installs (default for single projects)
+### Hoisted installs
 
 The traditional npm/Yarn approach that flattens dependencies into a shared `node_modules` directory:
 
@@ -249,7 +256,15 @@ bun install --linker isolated
 
 Isolated installs create a central package store in `node_modules/.bun/` with symlinks in the top-level `node_modules`. This ensures packages can only access their declared dependencies.
 
-For complete documentation on isolated installs, refer to [Package manager > Isolated installs](/pm/isolated-installs).
+### Default strategy
+
+The default linker strategy depends on whether you're starting fresh or have an existing project:
+
+- **New workspaces/monorepos**: `isolated` (prevents phantom dependencies)
+- **New single-package projects**: `hoisted` (traditional npm behavior)
+- **Existing projects (made pre-v1.3.2)**: `hoisted` (preserves backward compatibility)
+
+The default is controlled by a `configVersion` field in your lockfile. For a detailed explanation, see [Package manager > Isolated installs](/pm/isolated-installs).
 
 ---
 
@@ -319,8 +334,9 @@ dryRun = false
 concurrentScripts = 16 # (cpu count or GOMAXPROCS) x2
 
 # installation strategy: "hoisted" or "isolated"
-# default: "hoisted" (for single-project projects)
-# default: "isolated" (for monorepo projects)
+# default depends on lockfile configVersion and workspaces:
+# - configVersion = 1: "isolated" if using workspaces, otherwise "hoisted"
+# - configVersion = 0: "hoisted"
 linker = "hoisted"
 
 

package/docs/pm/cli/pm.mdx

@@ -115,6 +115,8 @@ To print a list of installed dependencies in the current project and their resol
 
 ```bash terminal icon="terminal"
 bun pm ls
+# or
+bun list
 ```
 
 ```txt
@@ -130,6 +132,8 @@ To print all installed dependencies, including nth-order dependencies.
 
 ```bash terminal icon="terminal"
 bun pm ls --all
+# or
+bun list --all
 ```
 
 ```txt

package/docs/pm/isolated-installs.mdx

@@ -5,7 +5,7 @@ description: "Strict dependency isolation similar to pnpm's approach"
 
 Bun provides an alternative package installation strategy called **isolated installs** that creates strict dependency isolation similar to pnpm's approach. This mode prevents phantom dependencies and ensures reproducible, deterministic builds.
 
-This is the default installation strategy for monorepo projects.
+This is the default installation strategy for **new** workspace/monorepo projects (with `configVersion = 1` in the lockfile). Existing projects continue using hoisted installs unless explicitly configured.
 
 ## What are isolated installs?
 
@@ -43,8 +43,23 @@ linker = "isolated"
 
 ### Default behavior
 
-- For monorepo projects, Bun uses the **isolated** installation strategy by default.
-- For single-project projects, Bun uses the **hoisted** installation strategy by default.
+The default linker strategy depends on your project's lockfile `configVersion`:
+
+| `configVersion` | Using workspaces? | Default Linker |
+| --------------- | ----------------- | -------------- |
+| `1`             | ✅                | `isolated`     |
+| `1`             | ❌                | `hoisted`      |
+| `0`             | ✅                | `hoisted`      |
+| `0`             | ❌                | `hoisted`      |
+
+**New projects**: Default to `configVersion = 1`. In workspaces, v1 uses the isolated linker by default; otherwise it uses hoisted linking.
+
+**Existing Bun projects (made pre-v1.3.2)**: If your existing lockfile doesn't have a version yet, Bun sets `configVersion = 0` when you run `bun install`, preserving the previous hoisted linker default.
+
+**Migrations from other package managers**:
+
+- From pnpm: `configVersion = 1` (using isolated installs in workspaces)
+- From npm or yarn: `configVersion = 0` (using hoisted installs)
 
 You can override the default behavior by explicitly specifying the `--linker` flag or setting it in your configuration file.
 

package/docs/project/benchmarking.mdx

@@ -216,3 +216,26 @@ numa nodes:       1
    elapsed:       0.068 s
    process: user: 0.061 s, system: 0.014 s, faults: 0, rss: 57.4 MiB, commit: 64.0 MiB
 ```
+
+## CPU profiling
+
+Profile JavaScript execution to identify performance bottlenecks with the `--cpu-prof` flag.
+
+```sh terminal icon="terminal"
+bun --cpu-prof script.js
+```
+
+This generates a `.cpuprofile` file you can open in Chrome DevTools (Performance tab → Load profile) or VS Code's CPU profiler.
+
+### Options
+
+```sh terminal icon="terminal"
+bun --cpu-prof --cpu-prof-name my-profile.cpuprofile script.js
+bun --cpu-prof --cpu-prof-dir ./profiles script.js
+```
+
+| Flag                         | Description          |
+| ---------------------------- | -------------------- |
+| `--cpu-prof`                 | Enable profiling     |
+| `--cpu-prof-name <filename>` | Set output filename  |
+| `--cpu-prof-dir <dir>`       | Set output directory |

package/docs/runtime/bunfig.mdx

@@ -497,7 +497,7 @@ print = "yarn"
 
 ### `install.linker`
 
-Configure the default linker strategy. Default `"hoisted"` for single-project projects, `"isolated"` for monorepo projects.
+Configure the linker strategy for installing dependencies. Defaults to `"isolated"` for new workspaces, `"hoisted"` for new single-package projects and existing projects (made pre-v1.3.2).
 
 For complete documentation refer to [Package manager > Isolated installs](/pm/isolated-installs).
 

package/docs/runtime/http/websockets.mdx

@@ -212,6 +212,9 @@ const server = Bun.serve({
       // this is a group chat
       // so the server re-broadcasts incoming message to everyone
       server.publish("the-group-chat", `${ws.data.username}: ${message}`);
+
+      // inspect current subscriptions
+      console.log(ws.subscriptions); // ["the-group-chat"]
     },
     close(ws) {
       const msg = `${ws.data.username} has left the chat`;
@@ -393,6 +396,7 @@ interface ServerWebSocket {
   readonly data: any;
   readonly readyState: number;
   readonly remoteAddress: string;
+  readonly subscriptions: string[];
   send(message: string | ArrayBuffer | Uint8Array, compress?: boolean): number;
   close(code?: number, reason?: string): void;
   subscribe(topic: string): void;

package/docs/test/lifecycle.mdx

@@ -5,12 +5,13 @@ description: "Learn how to use beforeAll, beforeEach, afterEach, and afterAll li
 
 The test runner supports the following lifecycle hooks. This is useful for loading test fixtures, mocking data, and configuring the test environment.
 
-| Hook         | Description                 |
-| ------------ | --------------------------- |
-| `beforeAll`  | Runs once before all tests. |
-| `beforeEach` | Runs before each test.      |
-| `afterEach`  | Runs after each test.       |
-| `afterAll`   | Runs once after all tests.  |
+| Hook             | Description                                                |
+| ---------------- | ---------------------------------------------------------- |
+| `beforeAll`      | Runs once before all tests.                                |
+| `beforeEach`     | Runs before each test.                                     |
+| `afterEach`      | Runs after each test.                                      |
+| `afterAll`       | Runs once after all tests.                                 |
+| `onTestFinished` | Runs after a single test finishes (after all `afterEach`). |
 
 ## Per-Test Setup and Teardown
 
@@ -90,6 +91,23 @@ describe("test group", () => {
 });
 ```
 
+### `onTestFinished`
+
+Use `onTestFinished` to run a callback after a single test completes. It runs after all `afterEach` hooks.
+
+```ts title="test.ts" icon="/icons/typescript.svg"
+import { test, onTestFinished } from "bun:test";
+
+test("cleanup after test", () => {
+  onTestFinished(() => {
+    // runs after all afterEach hooks
+    console.log("test finished");
+  });
+});
+```
+
+Not supported in concurrent tests; use `test.serial` instead.
+
 ## Global Setup and Teardown
 
 To scope the hooks to an entire multi-file test run, define the hooks in a separate file.

package/index.d.ts

@@ -20,7 +20,6 @@
 /// <reference path="./deprecated.d.ts" />
 /// <reference path="./redis.d.ts" />
 /// <reference path="./shell.d.ts" />
-/// <reference path="./experimental.d.ts" />
 /// <reference path="./serve.d.ts" />
 /// <reference path="./sql.d.ts" />
 /// <reference path="./security.d.ts" />

package/package.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.3.3-canary.20251109T140619",
+  "version": "1.3.3-canary.20251111T140653",
   "name": "bun-types",
   "license": "MIT",
   "types": "./index.d.ts",
@@ -23,12 +23,6 @@
   "dependencies": {
     "@types/node": "*"
   },
-  "peerDependencies": {
-    "@types/react": "^19"
-  },
-  "devDependencies": {
-    "@types/react": "^19"
-  },
   "scripts": {
     "prebuild": "echo $(pwd)",
     "copy-docs": "rm -rf docs && cp -rL ../../docs/ ./docs && find ./docs -type f -name '*.{md,mdx}' -exec sed -i 's/\\$BUN_LATEST_VERSION/'\"${BUN_VERSION#bun-v}\"'/g' {} +",

package/experimental.d.ts

@@ -1,278 +0,0 @@
-declare module "bun" {
-  export namespace __experimental {
-    /**
-     * Base interface for static site generation route parameters.
-     *
-     * Supports both single string values and arrays of strings for dynamic route segments.
-     * This is typically used for route parameters like `[slug]`, `[...rest]`, or `[id]`.
-     *
-     * @warning These APIs are experimental and might be moved/changed in future releases.
-     *
-     * @example
-     * ```tsx
-     * // Simple slug parameter
-     * type BlogParams = { slug: string };
-     *
-     * // Multiple parameters
-     * type ProductParams = {
-     *   category: string;
-     *   id: string;
-     * };
-     *
-     * // Catch-all routes with string arrays
-     * type DocsParams = {
-     *   path: string[];
-     * };
-     * ```
-     */
-    export interface SSGParamsLike {
-      [key: string]: string | string[];
-    }
-
-    /**
-     * Configuration object for a single static route to be generated.
-     *
-     * Each path object contains the parameters needed to render a specific
-     * instance of a dynamic route at build time.
-     *
-     * @warning These APIs are experimental and might be moved/changed in future releases.
-     *
-     * @template Params - The shape of route parameters for this path
-     *
-     * @example
-     * ```tsx
-     * // Single blog post path
-     * const blogPath: SSGPath<{ slug: string }> = {
-     *   params: { slug: "my-first-post" }
-     * };
-     *
-     * // Product page with multiple params
-     * const productPath: SSGPath<{ category: string; id: string }> = {
-     *   params: {
-     *     category: "electronics",
-     *     id: "laptop-123"
-     *   }
-     * };
-     *
-     * // Documentation with catch-all route
-     * const docsPath: SSGPath<{ path: string[] }> = {
-     *   params: { path: ["getting-started", "installation"] }
-     * };
-     * ```
-     */
-    export interface SSGPath<Params extends SSGParamsLike = SSGParamsLike> {
-      params: Params;
-    }
-
-    /**
-     * Array of static paths to be generated at build time.
-     *
-     * This type represents the collection of all route configurations
-     * that should be pre-rendered for a dynamic route.
-     *
-     * @warning These APIs are experimental and might be moved/changed in future releases.
-     *
-     * @template Params - The shape of route parameters for these paths
-     *
-     * @example
-     * ```tsx
-     * // Array of blog post paths
-     * const blogPaths: SSGPaths<{ slug: string }> = [
-     *   { params: { slug: "introduction-to-bun" } },
-     *   { params: { slug: "performance-benchmarks" } },
-     *   { params: { slug: "getting-started-guide" } }
-     * ];
-     *
-     * // Mixed parameter types
-     * const productPaths: SSGPaths<{ category: string; id: string }> = [
-     *   { params: { category: "books", id: "javascript-guide" } },
-     *   { params: { category: "electronics", id: "smartphone-x" } }
-     * ];
-     * ```
-     */
-    export type SSGPaths<Params extends SSGParamsLike = SSGParamsLike> = SSGPath<Params>[];
-
-    /**
-     * Props interface for SSG page components.
-     *
-     * This interface defines the shape of props that will be passed to your
-     * static page components during the build process. The `params` object
-     * contains the route parameters extracted from the URL pattern.
-     *
-     * @warning These APIs are experimental and might be moved/changed in future releases.
-     *
-     * @template Params - The shape of route parameters for this page
-     *
-     * @example
-     * ```tsx
-     * // Blog post component props
-     * interface BlogPageProps extends SSGPageProps<{ slug: string }> {
-     *   // params: { slug: string } is automatically included
-     * }
-     *
-     * // Product page component props
-     * interface ProductPageProps extends SSGPageProps<{
-     *   category: string;
-     *   id: string;
-     * }> {
-     *   // params: { category: string; id: string } is automatically included
-     * }
-     *
-     * // Usage in component
-     * function BlogPost({ params }: BlogPageProps) {
-     *   const { slug } = params; // TypeScript knows slug is a string
-     *   return <h1>Blog post: {slug}</h1>;
-     * }
-     * ```
-     */
-    export interface SSGPageProps<Params extends SSGParamsLike = SSGParamsLike> {
-      params: Params;
-    }
-
-    /**
-     * React component type for SSG pages that can be statically generated.
-     *
-     * This type represents a React component that receives SSG page props
-     * and can be rendered at build time. The component can be either a regular
-     * React component or an async React Server Component for advanced use cases
-     * like data fetching during static generation.
-     *
-     * @warning These APIs are experimental and might be moved/changed in future releases.
-     *
-     * @template Params - The shape of route parameters for this page component
-     *
-     * @example
-     * ```tsx
-     * // Regular synchronous SSG page component
-     * const BlogPost: SSGPage<{ slug: string }> = ({ params }) => {
-     *   return (
-     *     <article>
-     *       <h1>Blog Post: {params.slug}</h1>
-     *       <p>This content was generated at build time!</p>
-     *     </article>
-     *   );
-     * };
-     *
-     * // Async React Server Component for data fetching
-     * const AsyncBlogPost: SSGPage<{ slug: string }> = async ({ params }) => {
-     *   // Fetch data during static generation
-     *   const post = await fetchBlogPost(params.slug);
-     *   const author = await fetchAuthor(post.authorId);
-     *
-     *   return (
-     *     <article>
-     *       <h1>{post.title}</h1>
-     *       <p>By {author.name}</p>
-     *       <div dangerouslySetInnerHTML={{ __html: post.content }} />
-     *     </article>
-     *   );
-     * };
-     *
-     * // Product page with multiple params and async data fetching
-     * const ProductPage: SSGPage<{ category: string; id: string }> = async ({ params }) => {
-     *   const [product, reviews] = await Promise.all([
-     *     fetchProduct(params.category, params.id),
-     *     fetchProductReviews(params.id)
-     *   ]);
-     *
-     *   return (
-     *     <div>
-     *       <h1>{product.name}</h1>
-     *       <p>Category: {params.category}</p>
-     *       <p>Price: ${product.price}</p>
-     *       <div>
-     *         <h2>Reviews ({reviews.length})</h2>
-     *         {reviews.map(review => (
-     *           <div key={review.id}>{review.comment}</div>
-     *         ))}
-     *       </div>
-     *     </div>
-     *   );
-     * };
-     * ```
-     */
-    export type SSGPage<Params extends SSGParamsLike = SSGParamsLike> = import("react").ComponentType<
-      SSGPageProps<Params>
-    >;
-
-    /**
-     * getStaticPaths is Bun's implementation of SSG (Static Site Generation) path determination.
-     *
-     * This function is called at your app's build time to determine which
-     * dynamic routes should be pre-rendered as static pages. It returns an
-     * array of path parameters that will be used to generate static pages for
-     * dynamic routes (e.g., [slug].tsx, [category]/[id].tsx).
-     *
-     * The function can be either synchronous or asynchronous, allowing you to
-     * fetch data from APIs, databases, or file systems to determine which paths
-     * should be statically generated.
-     *
-     * @warning These APIs are experimental and might be moved/changed in future releases.
-     *
-     * @template Params - The shape of route parameters for the dynamic route
-     *
-     * @returns An object containing an array of paths to be statically generated
-     *
-     * @example
-     * ```tsx
-     * // In pages/blog/[slug].tsx ———————————————————╮
-     * export const getStaticPaths: GetStaticPaths<{ slug: string }> = async () => {
-     *   // Fetch all blog posts from your CMS or API at build time
-     *   const posts = await fetchBlogPosts();
-     *
-     *   return {
-     *     paths: posts.map((post) => ({
-     *       params: { slug: post.slug }
-     *     }))
-     *   };
-     * };
-     *
-     * // In pages/products/[category]/[id].tsx
-     * export const getStaticPaths: GetStaticPaths<{
-     *   category: string;
-     *   id: string;
-     * }> = async () => {
-     *   // Fetch products from database
-     *   const products = await db.products.findMany({
-     *     select: { id: true, category: { slug: true } }
-     *   });
-     *
-     *   return {
-     *     paths: products.map(product => ({
-     *       params: {
-     *         category: product.category.slug,
-     *         id: product.id
-     *       }
-     *     }))
-     *   };
-     * };
-     *
-     * // In pages/docs/[...path].tsx (catch-all route)
-     * export const getStaticPaths: GetStaticPaths<{ path: string[] }> = async () => {
-     *   // Read documentation structure from file system
-     *   const docPaths = await getDocumentationPaths('./content/docs');
-     *
-     *   return {
-     *     paths: docPaths.map(docPath => ({
-     *       params: { path: docPath.split('/') }
-     *     }))
-     *   };
-     * };
-     *
-     * // Synchronous example with static data
-     * export const getStaticPaths: GetStaticPaths<{ id: string }> = () => {
-     *   const staticIds = ['1', '2', '3', '4', '5'];
-     *
-     *   return {
-     *     paths: staticIds.map(id => ({
-     *       params: { id }
-     *     }))
-     *   };
-     * };
-     * ```
-     */
-    export type GetStaticPaths<Params extends SSGParamsLike = SSGParamsLike> = () => MaybePromise<{
-      paths: SSGPaths<Params>;
-    }>;
-  }
-}