revert changes

crates/turbopack-browser/src/ecmascript/runtime.rs

@@ -6,8 +6,8 @@ use turbopack_core::{
     ident::AssetIdent,
 };
 use turbopack_ecmascript::chunk::{
-    ChunkingContext, EcmascriptChunk, EcmascriptChunkPlaceables, EcmascriptChunkRuntime,
-    EcmascriptChunkRuntimeContent,
+    EcmascriptChunk, EcmascriptChunkPlaceables, EcmascriptChunkRuntime,
+    EcmascriptChunkRuntimeContent, ChunkingContext,
 };
 
 use crate::ecmascript::content::EcmascriptDevChunkContent;

docs/pages/repo/docs/core-concepts/monorepos/configuring-workspaces.mdx

@@ -30,14 +30,14 @@ key:
       // custom configuration for the build task in this workspace
     },
     // new tasks only available in this workspace
-    "special-task": {}
+    "special-task": {},
   }
 }
 ```
 
 <Callout>
-  For now, the only valid value for the `extends` key is `["//"]`. `//` is a
-  special name used to identify the root directory of the monorepo.
+  For now, the only valid value for the `extends` key is `["//"]`.
+`//` is a special name used to identify the root directory of the monorepo.
 </Callout>
 
 Configuration in a workspace can override any of [the configurations for a
@@ -59,7 +59,7 @@ with a single `turbo.json` at the root like this:
 {
   "pipeline": {
     "build": {
-      "outputs": [".next/**", "!.next/cache/**", ".svelte-kit/**"]
+      "outputs": [".next/**", "!.next/cache/**", ".svelte-kit/**"],
     }
   }
 }
@@ -151,8 +151,8 @@ but continue to inherit any other tasks defined at the root.
 
 At first glance, Workspace Configurations may sound a lot like the
 [`workspace#task` syntax][3] in the root `turbo.json`. The features are
-similar, but have one significant difference: when you declare a Workspace-specific
-task configuration in the root `turbo.json`, it _completely_ overwrites the baseline
+similar, but have one significant difference: when you declare a Workspace-specific 
+task configuration in the root `turbo.json`, it _completely_ overwrites the baseline 
 task configuration. With a Workspace Configuration, the task configuration is merged
 instead.
 
@@ -166,7 +166,7 @@ app again. Without a Workspace-specific task, you might configure your root
     "build": {
       "outputMode": "hash-only",
       "inputs": ["src/**"],
-      "outputs": [".next/**", "!.next/cache/**"]
+      "outputs": [".next/**", "!.next/cache/**"],
     },
     "my-sveltekit-app#build": {
       "outputMode": "hash-only", // must duplicate this
@@ -186,8 +186,7 @@ you don't need to duplicate them. You only need to override `outputs`
 
 <Callout type="info">
   Although there are no plans to remove Workspace-specific task configurations,
-  we expect that Workspace Configurations can be used for most use cases
-  instead.
+  we expect that Workspace Configurations can be used for most use cases instead.
 </Callout>
 
 ## Limitations
@@ -219,7 +218,7 @@ they are intentional, rather than accidental:
       },
       "build": {
         // ✅ just use the task name!
-      }
+      },
     }
   }
   ```
@@ -232,7 +231,7 @@ they are intentional, rather than accidental:
       "build": {
         // ✅ It's still ok to have workspace#task in dependsOn!
         "dependsOn": ["some-pkg#compile"]
-      }
+      },
     }
   }
   ```

docs/pages/repo/docs/core-concepts/monorepos/running-tasks.mdx

@@ -5,7 +5,7 @@ description: Turborepo can run all your tasks.
 
 import { Callout } from "../../../../../components/Callout";
 import HeartIcon from "@heroicons/react/solid/HeartIcon";
-import { Tabs, Tab } from "../../../../../components/Tabs";
+import { Tabs, Tab } from '../../../../../components/Tabs'
 
 # Running Tasks in a Monorepo
 
@@ -94,10 +94,10 @@ monorepo. Here's a kitchen sink example:
       "outputs": [".next/**", "!.next/cache/**", ".svelte-kit/**"]
     },
     "deploy": {
-      // A workspace's `deploy` task depends on the `build`,
-      // `test`, and `lint` tasks of the same workspace
-      // being completed.
-      "dependsOn": ["build", "test", "lint"]
+        // A workspace's `deploy` task depends on the `build`,
+        // `test`, and `lint` tasks of the same workspace
+        // being completed.
+        "dependsOn": ["build", "test", "lint"]
     },
     "test": {
       // A workspace's `test` task depends on that workspace's
@@ -140,12 +140,12 @@ A sample pipeline that defines the root task `format` and opts the root into `te
       "outputs": [".next/**", "!.next/cache/**", ".svelte-kit/**"]
     },
     "test": {
-      "dependsOn": ["^build"]
+      "dependsOn": ["^build"],
     },
     // This will cause the "test" script to be included when
     // "turbo run test" is run
     "//#test": {
-      "dependsOn": []
+      "dependsOn": [],
     },
     // This will cause the "format" script in the root package.json
     // to be run when "turbo run format" is run. Since the general
@@ -247,6 +247,6 @@ A turbo build will only execute the `build` script for the `web` and `docs` work
   Turborepo's Pipeline API design and this page of documentation was inspired by
   [Microsoft's Lage
   project](https://microsoft.github.io/lage/docs/Tutorial/pipeline#defining-a-pipeline).
-  Shoutout to [Kenneth Chau](https://x.com/kenneth_chau) for the idea of fanning
-  out tasks in such a concise and elegant way.
+  Shoutout to [Kenneth Chau](https://x.com/kenneth_chau) for the idea of
+  fanning out tasks in such a concise and elegant way.
 </Callout>