Make all JSON code syntactically valid

files/en-us/learn_web_development/core/frameworks_libraries/svelte_deployment_next/index.md

@@ -99,11 +99,13 @@ By default, when you create a new app with `npx degit sveltejs/template my-svelt
 In the file `package.json` you can see that the `build` and `dev` scripts are just calling rollup:
 
 ```json
-"scripts": {
-  "build": "rollup -c",
-  "dev": "rollup -c -w",
-  "start": "sirv public"
-},
+{
+  "scripts": {
+    "build": "rollup -c",
+    "dev": "rollup -c -w",
+    "start": "sirv public"
+  }
+}
 ```
 
 In the `dev` script we are passing the `-w` argument, which tells rollup to watch files and rebuild on changes.

files/en-us/learn_web_development/extensions/client-side_tools/deployment/index.md

@@ -192,9 +192,11 @@ Let's get started.
 2. In your package.json, find your `scripts` member, and update it so that it contains the following test and build commands:
 
    ```json
-   "scripts": {
-     // …
-     "test": "vitest"
+   {
+     "scripts": {
+       // …
+       "test": "vitest"
+     }
    }
    ```
 

files/en-us/learn_web_development/extensions/client-side_tools/introducing_complete_toolchain/index.md

@@ -195,10 +195,12 @@ npx prettier --write ./index.html
 You can also replace `./index.html` with any other file or folder to format them. For example, `.` will format everything in the current directory. In case you may forget the syntax, you can add it as a custom script in your package.json too:
 
 ```json
-"scripts": {
-  // …
-  "format": "prettier --write ."
-},
+{
+  "scripts": {
+    // …
+    "format": "prettier --write ."
+  }
+}
 ```
 
 Now you can run the following to format the directory:

files/en-us/learn_web_development/extensions/client-side_tools/package_management/index.md

@@ -137,9 +137,12 @@ We will add two more lines to package.json:
 Add these lines right below the `"name"`:
 
 ```json
-"name": "npm-experiment",
-"type": "module",
-"private": true,
+{
+  "name": "npm-experiment",
+  "type": "module",
+  "private": true
+  // …
+}
 ```
 
 So this is the config file that defines your package. This is good for now, so let's move on.
@@ -155,8 +158,10 @@ npm install --save-dev vite
 Once that's done _All The Things_, take another look at your package.json file. You'll see that npm has added a new field, `devDependencies`:
 
 ```json
-"devDependencies": {
-  "vite": "^5.2.13"
+{
+  "devDependencies": {
+    "vite": "^5.2.13"
+  }
 }
 ```
 
@@ -368,17 +373,21 @@ This would run a custom script for starting our project in "development mode". I
 If you tried running this in your test project from earlier it would (likely) claim the "dev script is missing". This is because npm, Yarn (and the like) are looking for a property called `dev` in the `scripts` property of your `package.json` file. So, let's create a custom shorthand command — "dev" — in our `package.json`. If you followed the tutorial from earlier, you should have a `package.json` file inside your npm-experiment directory. Open it up, and its `scripts` member should look like this:
 
 ```json
-"scripts": {
-  "test": "echo \"Error: no test specified\" && exit 1",
-},
+{
+  "scripts": {
+    "test": "echo \"Error: no test specified\" && exit 1"
+  }
+}
 ```
 
 Update it so that it looks like this, and save the file:
 
 ```json
-"scripts": {
-  "dev": "vite"
-},
+{
+  "scripts": {
+    "dev": "vite"
+  }
+}
 ```
 
 We've added a custom `dev` command as an npm script.
@@ -398,11 +407,13 @@ This particular one may look unnecessary — `npm run dev` is more characters to
 You can add all kinds of things to the `scripts` property that help you do your job. For example, here's what Vite recommends in the template:
 
 ```json
-"scripts": {
-  "dev": "vite",
-  "build": "vite build",
-  "preview": "vite preview"
-},
+{
+  "scripts": {
+    "dev": "vite",
+    "build": "vite build",
+    "preview": "vite preview"
+  }
+}
 ```
 
 ## Summary

files/en-us/learn_web_development/extensions/server-side/express_nodejs/deployment/index.md

@@ -314,9 +314,11 @@ v16.17.1
 Open **package.json**, and add this information as an **engines > node** as shown (using the version number for your system).
 
 ```json
+{
   "engines": {
     "node": ">=22.0.0"
-  },
+  }
+}
 ```
 
 The hosting service might not support the specific indicated version of node, but this change should ensure that it attempts to use a version with the same major version number, or a more recent version.

files/en-us/learn_web_development/extensions/server-side/express_nodejs/development_environment/index.md

@@ -299,8 +299,10 @@ npm install eslint --save-dev
 The following entry would then be added to your application's **package.json**:
 
 ```json
-"devDependencies": {
-  "eslint": "^9.30.1"
+{
+  "devDependencies": {
+    "eslint": "^9.30.1"
+  }
 }
 ```
 
@@ -317,10 +319,12 @@ In addition to defining and fetching dependencies you can also define _named_ sc
 For example, to define a script to run the _eslint_ development dependency that we specified in the previous section we might add the following script block to our **package.json** file (assuming that our application source is in a folder `/src/js`):
 
 ```json
-"scripts": {
-  // …
-  "lint": "eslint src/js"
-  // …
+{
+  "scripts": {
+    // …
+    "lint": "eslint src/js"
+    // …
+  }
 }
 ```
 

files/en-us/learn_web_development/extensions/server-side/express_nodejs/skeleton_website/index.md

@@ -254,8 +254,10 @@ npm install -g nodemon
 If you open your project's **package.json** file you'll now see a new section with this dependency:
 
 ```json
- "devDependencies": {
+{
+  "devDependencies": {
     "nodemon": "^3.1.10"
+  }
 }
 ```
 
@@ -264,11 +266,13 @@ Because the tool isn't installed globally, we can't launch it from the command l
 - On Linux and macOS, the scripts section will look like this:
 
   ```json
+  {
     "scripts": {
       "start": "node ./bin/www",
       "devstart": "nodemon ./bin/www",
       "serverstart": "DEBUG=express-locallibrary-tutorial:* npm run devstart"
-    },
+    }
+  }
   ```
 
 - On Windows, the "serverstart" value would instead look like this (if using the command prompt):
@@ -357,11 +361,13 @@ We already modified this section in [Enable server restart on file changes](#ena
 These can be used to start the same **./bin/www** file with _nodemon_ rather than _node_ (this version of the scripts is for Linux and macOS, as discussed above).
 
 ```json
+{
   "scripts": {
     "start": "node ./bin/www",
     "devstart": "nodemon ./bin/www",
     "serverstart": "DEBUG=express-locallibrary-tutorial:* npm run devstart"
-  },
+  }
+}
 ```
 
 The dependencies include the _express_ package and the package for our selected view engine (_pug_).
@@ -376,14 +382,16 @@ The default versions in the generated project are a little out of date.
 Replace the dependencies section of your `package.json` file with the following text, which specifies the latest versions of these libraries at the time of writing:
 
 ```json
+{
   "dependencies": {
     "cookie-parser": "^1.4.7",
     "debug": "^4.4.1",
     "express": "^5.1.0",
     "http-errors": "~2.0.0",
     "morgan": "^1.10.0",
     "pug": "3.0.3"
-  },
+  }
+}
 ```
 
 Then update your installed dependencies using the command:

files/en-us/learn_web_development/extensions/testing/automated_testing/index.md

@@ -257,9 +257,9 @@ In the input version of the file, you may have noticed that we put an empty {{ht
 4. Add the following property to `package.json`:
 
    ```json
-   "browserslist": [
-     "last 5 versions"
-   ]
+   {
+     "browserslist": ["last 5 versions"]
+   }
    ```
 
 5. Change the default task to:

files/en-us/mdn/writing_guidelines/howto/json_structured_data/index.md

@@ -26,28 +26,30 @@ GroupData does exactly that: for each API, it lists the interfaces, properties,
 An entry in `GroupData.json` has the following structure:
 
 ```json
-"Name_of_the_API": {
-  "overview": ["name_of_the_overview_page"],
-  "guides": [
-    "name_of_guide_1",
-    (…)
-  ],
-  "interfaces": [
-    "name_of_interface_1",
-    (…)
-  ],
-  "methods": [
-    "name_of_additional_method_1",
-    (…)
-  ],
-  "properties": [
-    "name_of_additional_property_1",
-    (…)
-  ],
-  "events": [
-    "name_of_additional_property_1",
-    (…)
-  ]
+{
+  "Name_of_the_API": {
+    "overview": ["name_of_the_overview_page"],
+    "guides": [
+      "name_of_guide_1"
+      // …
+    ],
+    "interfaces": [
+      "name_of_interface_1"
+      // …
+    ],
+    "methods": [
+      "name_of_additional_method_1"
+      // …
+    ],
+    "properties": [
+      "name_of_additional_property_1"
+      // …
+    ],
+    "events": [
+      "name_of_additional_property_1"
+      // …
+    ]
+  }
 }
 ```
 
@@ -101,9 +103,11 @@ This inheritance data is used when building API sidebars and by the `\{{Inherita
 An entry in `InterfaceData.json` has the following structure:
 
 ```json
-"Name_of_the_interface": {
-  "inh": "Name_of_the_parent_interface",
-  "impl": []
+{
+  "Name_of_the_interface": {
+    "inh": "Name_of_the_parent_interface",
+    "impl": []
+  }
 }
 ```
 

files/en-us/mdn/writing_guidelines/howto/write_an_api_reference/sidebars/index.md

@@ -39,19 +39,23 @@ For example, look at the [Fetch API](/en-US/docs/Web/API/Fetch_API) page on MDN.
 The corresponding entry in `GroupData.json` looks like this:
 
 ```json
-"Fetch API": {
-    "overview":   [ "Fetch API"],
-    "interfaces": [ "Headers",
-                    "Request",
-                    "Response",
-                    "FetchController",
-                    "FetchObserver",
-                    "FetchSignal",
-                    "ObserverCallback" ],
-    "methods":    [ "fetch()" ],
+{
+  "Fetch API": {
+    "overview": ["Fetch API"],
+    "interfaces": [
+      "Headers",
+      "Request",
+      "Response",
+      "FetchController",
+      "FetchObserver",
+      "FetchSignal",
+      "ObserverCallback"
+    ],
+    "methods": ["fetch()"],
     "properties": [],
-    "events":     []
-},
+    "events": []
+  }
+}
 ```
 
 As you can see, we've used "Fetch API" for the name, and inside the object value we include a number of sub-members.

files/en-us/web/api/attribution_reporting_api/generating_reports/index.md

@@ -225,18 +225,25 @@ To declare filters:
 1. On source registration, add a `filter_data` field to the {{httpheader("Attribution-Reporting-Register-Source")}} header that defines the filter keys you will use to filter the conversions over on the trigger side. These are completely custom fields. For example, to specify only conversions on particular subdomains, and for particular products:
 
    ```json
-   "filter_data": {
-     "conversion_subdomain": ["electronics.megastore", "electronics2.megastore"],
-     "product": ["1234"]
+   {
+     "filter_data": {
+       "conversion_subdomain": [
+         "electronics.megastore",
+         "electronics2.megastore"
+       ],
+       "product": ["1234"]
+     }
    }
    ```
 
 2. On trigger registration, add a `filters` field to the {{httpheader("Attribution-Reporting-Register-Trigger")}} header. The following, for example, causes trigger interactions to match the above source registration, as they both contain the `"electronics.megastore"` `"conversion_subdomain"` field. The `"directory"` filter on the other hand is ignored when a match is attempted, because it was not included in the above source registration.
 
    ```json
-   "filters": {
-     "conversion_subdomain": ["electronics.megastore"],
-     "directory": ["/store/electronics"]
+   {
+     "filters": {
+       "conversion_subdomain": ["electronics.megastore"],
+       "directory": ["/store/electronics"]
+     }
    }
    ```
 

files/en-us/web/api/idbindex/objectstore/index.md

@@ -27,7 +27,7 @@ based on the index, not the primary key.
 The current object store is logged to the console: it should be returned something like
 this:
 
-```json
+```plain
 IDBObjectStore { name: "contactsList", keyPath: "id", indexNames: DOMStringList[7], transaction: IDBTransaction, autoIncrement: false }
 ```
 

files/en-us/web/api/launch_handler_api/index.md

@@ -16,8 +16,10 @@ The **Launch Handler API** allows developers to control how a [progressive web a
 You can specify launch behavior for your app by adding the [`launch_handler`](/en-US/docs/Web/Progressive_web_apps/Manifest/Reference/launch_handler) field to your web app manifest file. This has one sub-field, `client_mode`, which contains a string value specifying how the app should be launched and navigated to. For example:
 
 ```json
-"launch_handler": {
+{
+  "launch_handler": {
     "client_mode": "focus-existing"
+  }
 }
 ```