Make all JSON code syntactically valid

Author: Josh-Cena

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.