feat(docs): Update all config file references to say cedar.toml (#1132)

Author: Tobbe

docs/docs/auth/auth0.md

@@ -44,9 +44,9 @@ AUTH0_REDIRECT_URI="http://localhost:8910"
 AUTH0_AUDIENCE="..."
 ```
 
-Lastly, include all these env vars in the list of env vars that should be available to the web side in `redwood.toml`:
+Lastly, include all these env vars in the list of env vars that should be available to the web side in `cedar.toml`:
 
-```toml title="redwood.toml"
+```toml title="cedar.toml"
 [web]
   # ...
   includeEnvironmentVariables = [

docs/docs/auth/azure.md

@@ -61,9 +61,9 @@ AZURE_ACTIVE_DIRECTORY_REDIRECT_URI="http://localhost:8910"
 AZURE_ACTIVE_DIRECTORY_LOGOUT_REDIRECT_URI="http://localhost:8910/login"
 ```
 
-That's it for .env vars. Don't forget to include them in the `includeEnvironmentVariables` array in `redwood.toml`:
+That's it for .env vars. Don't forget to include them in the `includeEnvironmentVariables` array in `cedar.toml`:
 
-```toml title="redwood.toml"
+```toml title="cedar.toml"
 [web]
   # ...
   includeEnvironmentVariables = [
@@ -152,7 +152,7 @@ AZURE_ACTIVE_DIRECTORY_JWT_ISSUER=https://rwauthtestb2c.b2clogin.com/775527ef-8a
 AZURE_ACTIVE_DIRECTORY_KNOWN_AUTHORITY=https://rwauthtestb2c.b2clogin.com
 ```
 
-And don't forget to add `AZURE_ACTIVE_DIRECTORY_KNOWN_AUTHORITY` to the `includeEnvironmentVariables` array in `redwood.toml`.
+And don't forget to add `AZURE_ACTIVE_DIRECTORY_KNOWN_AUTHORITY` to the `includeEnvironmentVariables` array in `cedar.toml`.
 (`AZURE_ACTIVE_DIRECTORY_JWT_ISSUER` is only used on the API side. But more importantly, it's sensitive—do _not_ include it in the web side.)
 
 #### Update `activeDirectoryClient` instance

docs/docs/auth/clerk.md

@@ -44,9 +44,9 @@ CLERK_PUBLISHABLE_KEY="..."
 CLERK_SECRET_KEY="..."
 ```
 
-Lastly, in your project's `redwood.toml` file, include `CLERK_PUBLISHABLE_KEY` in the list of env vars that should be available to the web side:
+Lastly, in your project's `cedar.toml` file, include `CLERK_PUBLISHABLE_KEY` in the list of env vars that should be available to the web side:
 
-```toml title="redwood.toml"
+```toml title="cedar.toml"
 [web]
   # ...
   includeEnvironmentVariables = [

docs/docs/auth/custom.md

@@ -83,13 +83,13 @@ yarn workspace web add @nhost/nhost-js
 
 Then we'll have to make an account, an application, and get it's `backendUrl`.
 On your application's dashboard, click "Settings" at the bottom of the the nav on the left, then "Environment Variables", and look for "NHOST_BACKEND_URL".
-Copy its value into your project's `.env` file and include it in the list of env vars the web side has access to in your project's `redwood.toml` file:
+Copy its value into your project's `.env` file and include it in the list of env vars the web side has access to in your project's `cedar.toml` file:
 
 ```bash title=".env"
 NHOST_BACKEND_URL="..."
 ```
 
-```toml title="redwood.toml"
+```toml title="cedar.toml"
 [web]
   # ...
   includeEnvironmentVariables = ["NHOST_BACKEND_URL"]
@@ -227,7 +227,7 @@ Time for another trip to your Nhost application's dashboard.
 This time you're looking for "NHOST_JWT_SECRET".
 Just like "NHOST_BACKEND_URL", it should be in "Settings", "Environment Variables".
 (This one is a JSON object, with two properties, `type` and `key`. We just need `key`.)
-Add that one to your project's `.env` file (no need to put it in `redwood.toml` though):
+Add that one to your project's `.env` file (no need to put it in `cedar.toml` though):
 
 ```shell title=".env"
 NHOST_JWT_SECRET="..."

docs/docs/auth/firebase.md

@@ -31,7 +31,7 @@ FIREBASE_PROJECT_ID="..."
 
 Lastly, include `FIREBASE_API_KEY` and `FIREBASE_AUTH_DOMAIN` in the list of env vars that should be available to the web side (`FIREBASE_PROJECT_ID` is for the api side):
 
-```toml title="redwood.toml"
+```toml title="cedar.toml"
 [web]
   # ...
   includeEnvironmentVariables = ["FIREBASE_API_KEY", "FIREBASE_AUTH_DOMAIN"]

docs/docs/auth/netlify.md

@@ -27,7 +27,7 @@ Right now, if we sign up, we'll have to verify our email address.
 Let's forego that feature for the purposes of this doc: click "Settings and usage", then scroll down to "Emails" and look for "Confirmation template".
 Click "Edit settings", tick the box next to "Allow users to sign up without verifying their email address", and click "Save".
 
-Netlify Identity works a little differently than the other auth providers in that you don't have to copy API keys to your project's `.env` and `redwood.toml` files.
+Netlify Identity works a little differently than the other auth providers in that you don't have to copy API keys to your project's `.env` and `cedar.toml` files.
 Instead, the first time you use it (by, say, calling `signUp` from `useAuth`), it'll ask you for your app's API endpoint.
 So let's go ahead and use it: if this is a brand new project, generate a home page.
 There we'll try to sign up by destructuring `signUp` from the `useAuth` hook (import that from `'src/auth'`). We'll also destructure and display `isAuthenticated` to see if it worked:

docs/docs/auth/supabase.md

@@ -34,9 +34,9 @@ SUPABASE_KEY="..."
 SUPABASE_JWT_SECRET="..."
 ```
 
-Lastly, in `redwood.toml`, include `SUPABASE_URL` and `SUPABASE_KEY` in the list of env vars that should be available to the web side:
+Lastly, in `cedar.toml`, include `SUPABASE_URL` and `SUPABASE_KEY` in the list of env vars that should be available to the web side:
 
-```toml title="redwood.toml"
+```toml title="cedar.toml"
 [web]
   # ...
   includeEnvironmentVariables = ["SUPABASE_URL", "SUPABASE_KEY"]

docs/docs/auth/supertokens.md

@@ -65,9 +65,9 @@ SUPERTOKENS_GOOGLE_CLIENT_ID=1060725074195-kmeum4crr01uirfl2op9kd5acmi9jutn.apps
 SUPERTOKENS_GOOGLE_CLIENT_SECRET=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
 ```
 
-## `redwood.toml` setup
+## `cedar.toml` setup
 
-Make sure to modify `redwood.toml` to pass the required environment variables to the web side:
+Make sure to modify `cedar.toml` to pass the required environment variables to the web side:
 
 ```toml
 [web]

docs/docs/cli-commands.md

@@ -1090,8 +1090,8 @@ will output the following files, with the components and pages nested in a `Post
   √ Adding scaffold asset imports...
 ```
 
-If it is not desired to nest the components and pages, then redwood provides an option that you can set to disable this for your project.
-Add the following in your `redwood.toml` file to disable the nesting of components and pages.
+If it is not desired to nest the components and pages, then Cedar provides an option that you can set to disable this for your project.
+Add the following in your `cedar.toml` file to disable the nesting of components and pages.
 
 ```
 [generate]
@@ -1106,7 +1106,7 @@ Notes:
 
 **Namespacing Scaffolds**
 
-You can namespace your scaffolds by providing `<path/model>`. The layout, pages, cells, and components will be nested in newly created dir(s). In addition, the nesting folder, based upon the model name, is still applied after the path for components and pages, unless turned off in the `redwood.toml` as described above. For example, given a model `user`, running `yarn redwood generate scaffold admin/user` will nest the layout, pages, and components in a newly created `Admin` directory created for each of the `layouts`, `pages`, and `components` folders:
+You can namespace your scaffolds by providing `<path/model>`. The layout, pages, cells, and components will be nested in newly created dir(s). In addition, the nesting folder, based upon the model name, is still applied after the path for components and pages, unless turned off in the `cedar.toml` as described above. For example, given a model `user`, running `yarn redwood generate scaffold admin/user` will nest the layout, pages, and components in a newly created `Admin` directory created for each of the `layouts`, `pages`, and `components` folders:
 
 ```plaintext {9-20}
 ~/redwood-app$ yarn redwood generate scaffold admin/user
@@ -1167,9 +1167,9 @@ yarn redwood destroy scaffold <model>
 
 Notes:
 
-1. You can also use `<path/model>` to destroy files that were generated under a scaffold path. For example, `redwood d scaffold admin/post`
+1. You can also use `<path/model>` to destroy files that were generated under a scaffold path. For example, `cedar d scaffold admin/post`
 2. The destroy command will remove empty folders along the path, provided they are lower than the folder level of component, layout, page, etc.
-3. The destroy scaffold command will also follow the `nestScaffoldbyModel` setting in the `redwood.toml` file. For example, if you have an existing scaffold that you wish to destroy, that does not have the pages and components nested by the model name, you can destroy the scaffold by temporarily setting:
+3. The destroy scaffold command will also follow the `nestScaffoldbyModel` setting in the `cedar.toml` file. For example, if you have an existing scaffold that you wish to destroy, that does not have the pages and components nested by the model name, you can destroy the scaffold by temporarily setting:
 
 ```
 [generate]
@@ -1916,7 +1916,7 @@ Netlify Dev can also create a tunnel from your local development server that all
   # to connect your local project to a site already on Netlify
   # then run netlify dev and our app will be accessible on the port specified below
   framework = "redwoodjs"
-  # Set targetPort to the [web] side port as defined in redwood.toml
+  # Set targetPort to the [web] side port as defined in cedar.toml
   targetPort = 8910
   # Point your browser to this port to access your CedarJS app
   port = 8888
@@ -1926,7 +1926,7 @@ In order to use [Netlify Dev](https://www.netlify.com/products/dev/) you need to
 
 - install the latest [netlify-cli](https://docs.netlify.com/cli/get-started/#installation)
 - use [netlify link](https://docs.netlify.com/cli/get-started/#link-and-unlink-sites) to connect to your Netlify site
-- ensure that the `targetPort` matches the [web] side port in `redwood.toml`
+- ensure that the `targetPort` matches the [web] side port in `cedar.toml`
 - run `netlify dev` and your site will be served on the specified `port` (e.g., 8888)
 - if you wish to share your local server with others, you can run `netlify dev --live`
 
@@ -2050,7 +2050,7 @@ If you have not setup the CedarJS server file, it will be setup:
 
 ```bash
 ✔ Adding the experimental server file...
-✔ Adding config to redwood.toml...
+✔ Adding config to cedar.toml...
 ✔ Adding required api packages...
 ```
 
@@ -2094,7 +2094,7 @@ If you have not setup the CedarJS server file, it will be setup:
 
 ```bash
 ✔ Adding the experimental server file...
-✔ Adding config to redwood.toml...
+✔ Adding config to cedar.toml...
 ✔ Adding required api packages...
 ```
 
@@ -2206,7 +2206,7 @@ Runs a server that only serves the api side.
 yarn rw serve api
 ```
 
-This command uses `apiUrl` in your `redwood.toml`. Use this command if you want to run just the api side on a server (e.g. running on Render).
+This command uses `apiUrl` in your `cedar.toml`. Use this command if you want to run just the api side on a server (e.g. running on Render).
 
 | Arguments & Options | Description                                                       |
 | ------------------- | ----------------------------------------------------------------- |
@@ -2235,11 +2235,11 @@ This command serves the contents in `web/dist`. Use this command if you're debug
 >
 > Probably, but it can be a challenge to setup when you just want something running quickly!
 
-| Arguments & Options | Description                                                                           |
-| ------------------- | ------------------------------------------------------------------------------------- |
-| `--port`            | What port should the server run on [default: 8911]                                    |
-| `--socket`          | The socket the server should run. This takes precedence over port                     |
-| `--apiHost`         | Forwards requests from the `apiUrl` (defined in `redwood.toml`) to the specified host |
+| Arguments & Options | Description                                                                         |
+| ------------------- | ----------------------------------------------------------------------------------- |
+| `--port`            | What port should the server run on [default: 8911]                                  |
+| `--socket`          | The socket the server should run. This takes precedence over port                   |
+| `--apiHost`         | Forwards requests from the `apiUrl` (defined in `cedar.toml`) to the specified host |
 
 If you want to format your log output, you can pipe the command to the Cedar LogFormatter:
 
@@ -2285,7 +2285,7 @@ yarn redwood upgrade -t 0.19.3
 The CLI can check for things in the background, like new versions of the framework, while you dev.
 
 Right now it can only check for new versions.
-If you'd like it to do so, set `notifications.versionUpdates` in the `redwood.toml` file to include an array of the tags you're interested in hearing about.
+If you'd like it to do so, set `notifications.versionUpdates` in the `cedar.toml` file to include an array of the tags you're interested in hearing about.
 (The former has priority.)
 
 By default, the CLI won't check for upgrades—you have to opt into it.

docs/docs/contributing-overview.md

@@ -133,7 +133,7 @@ How To's are tutorial-style content focused on a specific problem-solution. They
 
 If you write it, will they read it? We think they will—if they can find it.
 
-After you've finished writing, step back for a moment and consider the word(s) or phrase(s) people will use to find what you just wrote. For example, let's say you were writing a doc about configuring a Cedar app. If you didn't know much about configuring a Cedar app, a heading (in the nav bar to the left) like "redwood.toml" wouldn't make much sense, even though it _is_ the main configuration file. You'd probably look for "Cedar Config" or "Settings", or type "how to change Cedar App settings" in the "Search the docs" bar up top, or in Google.
+After you've finished writing, step back for a moment and consider the word(s) or phrase(s) people will use to find what you just wrote. For example, let's say you were writing a doc about configuring a Cedar app. If you didn't know much about configuring a Cedar app, a heading (in the nav bar to the left) like "cedar.toml" wouldn't make much sense, even though it _is_ the main configuration file. You'd probably look for "Cedar Config" or "Settings", or type "how to change Cedar App settings" in the "Search the docs" bar up top, or in Google.
 
 That is to say, the most useful headings aren't always the most literal ones. Indexing is more than just underlining the "important" words in a text—it's identifying and locating the concepts and topics that are the most relevant to our readers, the users of our documentation.