docs: updated references to deno.json(c) across documentation

frontend/docs/about-slow-types.md

@@ -413,7 +413,7 @@ to `jsr publish` or `deno publish`.
 When using Deno, one can supress slow type diagnostics from being surfaced in
 `deno lint` by adding an exclude for the `no-slow-types` rule. This can be done
 by specifying `--rules-exclude=no-slow-types` when running `deno lint`, or by
-adding the following to your `deno.json` configuration file:
+adding the following to your `deno.json(c)` configuration file:
 
 ```json
 {

frontend/docs/introduction.md

@@ -80,7 +80,7 @@ like the name, version, and entrypoint(s). The
 modules should be importable by users of your package.
 
 ```json
-// jsr.json / deno.json
+// jsr.json / deno.json(c)
 {
   "name": "@luca/greet",
   "version": "1.0.0",

frontend/docs/migrate-x-to-jsr.md

@@ -50,8 +50,8 @@ build for your platform with:
 deno upgrade --canary
 ```
 
-Then, from within your package folder (probably the one with your `deno.json` or
-`mod.ts`), execute the following command:
+Then, from within your package folder (probably the one with your `deno.json(c)`
+or `mod.ts`), execute the following command:
 
 ```bash
 deno run -Ar jsr:@deno/x-to-jsr
@@ -99,7 +99,7 @@ _Vendor dependencies_
 
 You can also
 [vendor your dependencies](https://docs.deno.com/runtime/manual/basics/vendoring/)
-by adding `"vendor": true` to your `deno.json` file. This will download local
+by adding `"vendor": true` to your `deno.json(c)` file. This will download local
 versions of your HTTPS dependencies to a `vendor` directory when the project is
 ran.
 

frontend/docs/native-imports.md

@@ -54,7 +54,7 @@ constraints in your code, you can use
 to map the `jsr:` scheme to a different prefix.
 
 In **Deno** you can do this by adding a line to the `"imports"` section in your
-`deno.json`. You can do this manually, or by using the `deno add` command:
+`deno.json(c)`. You can do this manually, or by using the `deno add` command:
 
 ```diff
  {
@@ -64,7 +64,7 @@ In **Deno** you can do this by adding a line to the `"imports"` section in your
  }
 ```
 
-You can then import packages using the alias defined in the `deno.json`:
+You can then import packages using the alias defined in the `deno.json(c)`:
 
 ```ts
 import { camelCase } from "@luca/cases";

frontend/docs/npm-compatibility.md

@@ -172,7 +172,7 @@ are generated by JSR, and contain all source code reachable from the entrypoint
 of the package. This source code is transpiled to JavaScript, and TypeScript
 type declarations (`.d.ts` files) are generated for all TypeScript files. The
 tarball also contains a `package.json` file that contains the `exports` field
-from the original `jsr.json` / `deno.json` file.
+from the original `jsr.json` / `deno.json(c)` file.
 
 Yanked versions of packages are not advertised in the package version manifest
 of the npm registry endpoint. Tarballs for yanked versions are still available

frontend/docs/package-configuration.md

@@ -9,7 +9,7 @@ file can instead be placed in the
 [`deno.json`](https://docs.deno.com/runtime/manual/getting_started/configuration_file).
 
 ```json
-// jsr.json / deno.json
+// jsr.json / deno.json(c)
 {
   "name": "@luca/greet",
   "version": "1.0.0",
@@ -36,7 +36,7 @@ your package. The `exports` field can either be specified as a single string, or
 as an object mapping entrypoint names to paths in your package.
 
 ```json
-// jsr.json / deno.json
+// jsr.json / deno.json(c)
 {
   "name": "@luca/greet",
   "version": "1.0.0",
@@ -58,7 +58,7 @@ you only have a single entrypoint in your package. It is semantically equivalent
 to specifying a default entrypoint in the object form.
 
 ```diff
-// deno.json
+// deno.json(c)
 {
   "name": "@luca/greet",
   "version": "1.0.0",
@@ -72,9 +72,9 @@ to specifying a default entrypoint in the object form.
 ### `include` and `exclude`
 
 You can also use the `include` and `exclude` options to include and exclude
-files during publishing. When using a `deno.json`, you can use `publish.include`
-and `publish.exclude` to include and exclude files only for publishing, rather
-than for all Deno subcommands.
+files during publishing. When using a `deno.json(c)`, you can use
+`publish.include` and `publish.exclude` to include and exclude files only for
+publishing, rather than for all Deno subcommands.
 [Learn more about filtering files](/docs/publishing-packages#filtering-files).
 
 ## JSON Schema

frontend/docs/publishing-packages.md

@@ -101,7 +101,7 @@ export * from "./greet.ts";
 ### Importing npm packages
 
 You may import npm packages specified in the `"dependencies"` of a
-`package.json`, ones specified in an import map or `deno.json`, or ones
+`package.json`, ones specified in an import map or `deno.json(c)`, or ones
 specified in source code using `npm:` specifiers.
 
 ```json
@@ -123,7 +123,7 @@ import * as express from "npm:express@4";
 ### Importing JSR packages
 
 You may import JSR packages specified in the `"dependencies"` of a
-`package.json`, ones specified in an import map or `deno.json`, or ones
+`package.json`, ones specified in an import map or `deno.json(c)`, or ones
 specified in source code using `jsr:` specifiers.
 [Learn more about using packages.](/docs/using-packages)
 
@@ -161,13 +161,13 @@ export function readJsonFile(path: string) {
 
 You may use a dependency manifest like a `package.json`, or an
 [import map](https://docs.deno.com/runtime/manual/basics/import_maps) (like the
-`deno.json` file) to simplify your imports. During publishing, `jsr publish` /
-`deno publish` will automatically rewrite the specifiers in your source code to
-fully qualified specifiers that do not require an import map / `package.json`
+`deno.json(c)` file) to simplify your imports. During publishing, `jsr publish`
+/ `deno publish` will automatically rewrite the specifiers in your source code
+to fully qualified specifiers that do not require an import map / `package.json`
 anymore.
 
 ```json
-// import_map.json / deno.json
+// import_map.json / deno.json(c)
 {
   "imports": {
     "@luca/greet": "jsr:@luca/greet@1",
@@ -201,10 +201,10 @@ consumers of your package.
 After you have written your code, you must add a config file to your package.
 This file contains package metadata like the name, version, and entrypoint(s).
 This file should be named `jsr.json`. Deno users can also include the required
-JSR properties in their `deno.json` to avoid having to create another file.
+JSR properties in their `deno.json(c)` to avoid having to create another file.
 
 ```json
-// jsr.json / deno.json
+// jsr.json / deno.json(c)
 {
   "name": "@luca/greet",
   "version": "1.0.0",
@@ -346,16 +346,16 @@ jobs:
 
 This workflow will run every time you push to the `main` branch of your
 repository. It will publish your package to JSR, and will automatically use the
-correct version number based on the version in your `jsr.json` file.
-`jsr publish` will not attempt to publish if the version specified in your
-`jsr.json` file is already published to JSR.
+correct version number based on the version in your `jsr.json`/`deno.json(c)`
+file. `jsr publish` will not attempt to publish if the version specified in your
+`jsr.json`/`deno.json(c)` file is already published to JSR.
 
 ## Filtering files
 
 `jsr publish` will ignore files that are listed in a `.gitignore` file in the
 root of your package. Additionally, you can specify the `include` and `exclude`
-fields in your `jsr.json` / `deno.json` file to include, ignore, or un-gitignore
-specific files.
+fields in your `jsr.json` / `deno.json(c)` file to include, ignore, or
+un-gitignore specific files.
 
 For example, to only selectively include certain files, you can specify a glob
 that matches all files by using the `include` option:
@@ -398,13 +398,13 @@ You may also exclude certain files via the `exclude` option:
 }
 ```
 
-When using Deno, the `include` and `exclude` options in `deno.json` are used for
-many other Deno subcommands as well, such as `deno test`, `deno lint` and
+When using Deno, the `include` and `exclude` options in `deno.json(c)` are used
+for many other Deno subcommands as well, such as `deno test`, `deno lint` and
 `deno fmt`. You can use `publish.include` and `publish.exclude` in your
-`deno.json` file to specify options that only apply to `deno publish`.
+`deno.json(c)` file to specify options that only apply to `deno publish`.
 
 ```json
-// deno.json
+// deno.json(c)
 {
   "name": "@luca/greet",
   "version": "1.0.0",
@@ -431,7 +431,7 @@ be ignored when publishing.
 This may however be inconvenient if you want to publish the `dist/` directory,
 because you have `"exports"` pointing to it (or a subdirectory of it). In this
 case, you can un-ignore the `dist/` directory by using a negation in the
-`exclude` field in your `jsr.json` / `deno.json` file.
+`exclude` field in your `jsr.json` / `deno.json(c)` file.
 
 ```json
 // jsr.json