diff --git a/next.config.js b/next.config.js index 0279b73f..d5d348bf 100644 --- a/next.config.js +++ b/next.config.js @@ -4,9 +4,9 @@ // let assetPrefix = undefined; ///** Deploys as a directory through GitHub Actions **/ -//const isGithubActions = process.env.GITHUB_ACTIONS || false +//const isGitHubActions = process.env.GITHUB_ACTIONS || false // -//if (isGithubActions) { +//if (isGitHubActions) { // // trim off `/` // const repo = process.env.GITHUB_REPOSITORY.replace(/.*?\//, '') // diff --git a/pages/aws/config.mdx b/pages/aws/config.mdx index bcee5d4e..fc9811d5 100644 --- a/pages/aws/config.mdx +++ b/pages/aws/config.mdx @@ -7,7 +7,7 @@ There is two build arguments that you can pass to the `open-next build` command: ### Configuration File -For personalisation you need to create a file `open-next.config.ts` at the same place as your `next.config.js`, and export a default object that satisfies the `OpenNextConfig` interface. It is possible to not have an `open-next.config.ts` file, the default configuration will then be applied automatically. +For personalization you need to create a file `open-next.config.ts` at the same place as your `next.config.js`, and export a default object that satisfies the `OpenNextConfig` interface. It is possible to not have an `open-next.config.ts` file, the default configuration will then be applied automatically. This file needs to be placed at the same level as your `next.config.js` file. diff --git a/pages/aws/config/nx.mdx b/pages/aws/config/nx.mdx index b635c249..0aa7e552 100644 --- a/pages/aws/config/nx.mdx +++ b/pages/aws/config/nx.mdx @@ -159,7 +159,7 @@ export default $config({ $ cd apps/next-site && sst install ``` -this will resolve the type issues and initialise SST. +this will resolve the type issues and initialize SST. - next we need to add `sst.config.ts` to our `tsconfig.json`'s excludes array diff --git a/pages/aws/contribute/plugin.mdx b/pages/aws/contribute/plugin.mdx index 2ecd0c24..1b92d733 100644 --- a/pages/aws/contribute/plugin.mdx +++ b/pages/aws/contribute/plugin.mdx @@ -16,7 +16,7 @@ openNextPlugin({ deletes: ["id1"], }) - //To inject arbritary code by using (import at top of file): + //To inject arbitrary code by using (import at top of file): //#import @@ -63,7 +63,7 @@ openNextEdgePlugin({ nextDir: "next", // The path to the edgeFunctionHandler.js file that we'll use to bundle the routing edgeFunctionHandlerPath: "./edgeFunctionHandler.js", - // The middlewareInfo from the middlware manifest file + // The middlewareInfo from the middleware manifest file middlewareInfo: middlewareInfo // If the app should be bundled for cloudflare workers isInCloudflare: true diff --git a/pages/aws/inner_workings/components/overview.mdx b/pages/aws/inner_workings/components/overview.mdx index 481c97a5..804782e9 100644 --- a/pages/aws/inner_workings/components/overview.mdx +++ b/pages/aws/inner_workings/components/overview.mdx @@ -24,7 +24,7 @@ Every backend is a separate module. The following backends are available: - Warmer - Initializer -All these backends can be overrided to fit your needs. They share some common ground for the configuration and the way they are used. +All these backends can be overridden to fit your needs. They share some common ground for the configuration and the way they are used. ### Common Overrides diff --git a/pages/aws/v2/inner_workings/plugin.mdx b/pages/aws/v2/inner_workings/plugin.mdx index 573eb8a4..24579667 100644 --- a/pages/aws/v2/inner_workings/plugin.mdx +++ b/pages/aws/v2/inner_workings/plugin.mdx @@ -1,6 +1,6 @@ import { Callout } from "nextra/components"; -Open-next use esbuild to build the project. Given that we aim to support multiple version of Next and multiple runtime, we developped a plugin to override some parts of our code at build time with an esbuild plugin. +Open-next use esbuild to build the project. Given that we aim to support multiple version of Next and multiple runtime, we developed a plugin to override some parts of our code at build time with an esbuild plugin. As of now, the plugin is internal and not exposed to the user. We might expose it in the future, but for diff --git a/pages/cloudflare/caching.mdx b/pages/cloudflare/caching.mdx index a43022ae..aa771a83 100644 --- a/pages/cloudflare/caching.mdx +++ b/pages/cloudflare/caching.mdx @@ -5,7 +5,7 @@ import { Tabs } from "nextra/components"; Next.js offers multiple ways to improve an application's performance by [caching](https://nextjs.org/docs/app/building-your-application/data-fetching/fetching-caching-and-revalidating#caching-data) routes and network requests. An application will try to pre-render and cache as much data as possible during build-time to reduce the amount of work required when serving a response to a user. -The cache data are updated using revalidation, either peridiocally or on-demand: +The cache data are updated using revalidation, either periodically or on-demand: - "[Time-based revalidation](https://nextjs.org/docs/app/building-your-application/data-fetching/incremental-static-regeneration#time-based-revalidation)" updates the cache data after the revalidation delay specified by the applications expires - "[On-demand revalidation](https://nextjs.org/docs/app/building-your-application/data-fetching/incremental-static-regeneration#on-demand-revalidation-with-revalidatetag)" allows to invalid cache entries with a specific tag (via `revalidateTag`) or at a given path (via `revalidatePath`). You can also use `res.revalidate` in Pages router API route. @@ -585,9 +585,9 @@ export default defineCloudflareConfig({ }); ``` -##### 4. Initialise the cache during deployments +##### 4. Initialize the cache during deployments -In order for the cache to be properly initialised with the build-time revalidation data, you need to run a command as part of your deploy step. This should be run as part of each deployment to ensure that the cache is being populated with each build's data. +In order for the cache to be properly initialized with the build-time revalidation data, you need to run a command as part of your deploy step. This should be run as part of each deployment to ensure that the cache is being populated with each build's data. To populate remote bindings and create a new [version](https://developers.cloudflare.com/workers/configuration/versions-and-deployments/#versions) of your application at the same time, you can use either the [`deploy`](/cloudflare/cli#deploy-command) command or the [`upload`](/cloudflare/cli#upload-command) command. Similarly, the [`preview`](/cloudflare/cli#preview-command) command will populate your local bindings and start a Wrangler dev server. diff --git a/pages/cloudflare/community.mdx b/pages/cloudflare/community.mdx index 3ccd11fa..44355330 100644 --- a/pages/cloudflare/community.mdx +++ b/pages/cloudflare/community.mdx @@ -17,7 +17,7 @@ Here is a list of some of the features it includes: - Rate Limiting with Cloudflare KV to prevent abuse - Validation for all user actions with react-zsa and zod - Database: Drizzle ORM and Cloudflare D1 -- UI: Shadcn, Tailwind CSS and Hero UI (formely NextUI) +- UI: `shadcn/ui`, Tailwind CSS and HeroUI (formerly NextUI) - Transactional email templates with react-email and integration with Resend and Brevo - Dev Experience - Completely type safe @@ -26,5 +26,5 @@ Here is a list of some of the features it includes: - .cursorrules - A markdown project documentation that Cursor can refer to for more context and better responses - Detailed documentation for local development and production deployment - - Automatic deployment using Github Actions and the Wrangler CLI + - Automatic deployment using GitHub Actions and the Wrangler CLI - And more... diff --git a/pages/cloudflare/former-releases/0.2/get-started.mdx b/pages/cloudflare/former-releases/0.2/get-started.mdx index 2e162139..0616e70a 100644 --- a/pages/cloudflare/former-releases/0.2/get-started.mdx +++ b/pages/cloudflare/former-releases/0.2/get-started.mdx @@ -137,4 +137,4 @@ Either deploy via the command line: npm run deploy:worker ``` -Or [connect a Github or Gitlab repository](https://developers.cloudflare.com/workers/ci-cd/), and Cloudflare will automatically build and deploy each pull request you merge to your production branch. +Or [connect a GitHub or GitLab repository](https://developers.cloudflare.com/workers/ci-cd/), and Cloudflare will automatically build and deploy each pull request you merge to your production branch. diff --git a/pages/cloudflare/former-releases/0.3/caching.mdx b/pages/cloudflare/former-releases/0.3/caching.mdx index 13148731..09b7b9a9 100644 --- a/pages/cloudflare/former-releases/0.3/caching.mdx +++ b/pages/cloudflare/former-releases/0.3/caching.mdx @@ -10,7 +10,7 @@ By default, all `fetch()` subrequests made in your Next.js app are cached. Refer Note that [Revalidating](https://nextjs.org/docs/app/building-your-application/data-fetching/fetching-caching-and-revalidating#revalidating-data) is not yet supported. -Next.js primes the cache at build time. The build time values are serverd by the [Workers Assets](https://developers.cloudflare.com/workers/static-assets/). +Next.js primes the cache at build time. The build time values are served by the [Workers Assets](https://developers.cloudflare.com/workers/static-assets/). Workers KV is eventually consistent, which means that it can take up to 60 seconds for updates to be diff --git a/pages/cloudflare/former-releases/0.3/get-started.mdx b/pages/cloudflare/former-releases/0.3/get-started.mdx index 1345e344..0ade82d7 100644 --- a/pages/cloudflare/former-releases/0.3/get-started.mdx +++ b/pages/cloudflare/former-releases/0.3/get-started.mdx @@ -191,4 +191,4 @@ Either deploy via the command line: npm run deploy:worker ``` -Or [connect a Github or Gitlab repository](https://developers.cloudflare.com/workers/ci-cd/), and Cloudflare will automatically build and deploy each pull request you merge to your production branch. +Or [connect a GitHub or GitLab repository](https://developers.cloudflare.com/workers/ci-cd/), and Cloudflare will automatically build and deploy each pull request you merge to your production branch. diff --git a/pages/cloudflare/former-releases/0.5/caching.mdx b/pages/cloudflare/former-releases/0.5/caching.mdx index c5eed523..738f24f0 100644 --- a/pages/cloudflare/former-releases/0.5/caching.mdx +++ b/pages/cloudflare/former-releases/0.5/caching.mdx @@ -4,7 +4,7 @@ import { Callout } from "nextra/components"; `@opennextjs/cloudflare` supports [caching](https://nextjs.org/docs/app/building-your-application/data-fetching/fetching-caching-and-revalidating#caching-data). -Next.js primes the cache at build time. The build time values are serverd by the [Workers Assets](https://developers.cloudflare.com/workers/static-assets/). +Next.js primes the cache at build time. The build time values are served by the [Workers Assets](https://developers.cloudflare.com/workers/static-assets/). Workers KV is eventually consistent, which means that it can take up to 60 seconds for updates to be @@ -143,9 +143,9 @@ export default defineCloudflareConfig({ }); ``` -##### 4. Initialise the cache during deployments +##### 4. Initialize the cache during deployments -In order for the cache to be properly initialised with the build-time revalidation data, you need to setup a command that runs as part of your deploy step. +In order for the cache to be properly initialized with the build-time revalidation data, you need to setup a command that runs as part of your deploy step. OpenNext will generate an SQL file during the build that can be used to setup your D1 database. diff --git a/pages/cloudflare/former-releases/0.5/get-started.mdx b/pages/cloudflare/former-releases/0.5/get-started.mdx index f1d70dd4..10cb3189 100644 --- a/pages/cloudflare/former-releases/0.5/get-started.mdx +++ b/pages/cloudflare/former-releases/0.5/get-started.mdx @@ -187,4 +187,4 @@ Either deploy via the command line: npm run deploy ``` -Or [connect a Github or Gitlab repository](https://developers.cloudflare.com/workers/ci-cd/), and Cloudflare will automatically build and deploy each pull request you merge to your production branch. +Or [connect a GitHub or GitLab repository](https://developers.cloudflare.com/workers/ci-cd/), and Cloudflare will automatically build and deploy each pull request you merge to your production branch. diff --git a/pages/cloudflare/former-releases/0.6/caching.mdx b/pages/cloudflare/former-releases/0.6/caching.mdx index 0f642d3d..47e94eb8 100644 --- a/pages/cloudflare/former-releases/0.6/caching.mdx +++ b/pages/cloudflare/former-releases/0.6/caching.mdx @@ -13,7 +13,7 @@ import { Tabs } from "nextra/components"; There are two storage options to use for the incremental cache. -- **Workers KV:** A [fast](https://blog.cloudflare.com/faster-workers-kv) and uses Cloudflare's [Tiered Cache](https://developers.cloudflare.com/cache/how-to/tiered-cache/) to increase cache hit rates. When you write cached data to Workers KV, you write to storage that can be read by any Cloudflare location. This means your app can fetch data, cache it in KV, and then subsequent requests anywhere around the world can read from this cache. The build time values are serverd by the [Workers Assets](https://developers.cloudflare.com/workers/static-assets/). Pricing information can be found in the Cloudflare [docs](https://developers.cloudflare.com/workers/platform/pricing/#workers-kv). +- **Workers KV:** A [fast](https://blog.cloudflare.com/faster-workers-kv) and uses Cloudflare's [Tiered Cache](https://developers.cloudflare.com/cache/how-to/tiered-cache/) to increase cache hit rates. When you write cached data to Workers KV, you write to storage that can be read by any Cloudflare location. This means your app can fetch data, cache it in KV, and then subsequent requests anywhere around the world can read from this cache. The build time values are served by the [Workers Assets](https://developers.cloudflare.com/workers/static-assets/). Pricing information can be found in the Cloudflare [docs](https://developers.cloudflare.com/workers/platform/pricing/#workers-kv). - **R2 Object Storage:** A [cost-effective](https://developers.cloudflare.com/r2/pricing/) S3-compatible object storage option for large amounts of unstructured data. Data is stored in a single region, meaning cache interactions may be slower - this can be mitigated with a regional cache. @@ -393,9 +393,9 @@ export default defineCloudflareConfig({ }); ``` -##### 3. Initialise the cache during deployments +##### 3. Initialize the cache during deployments -In order for the cache to be properly initialised with the build-time revalidation data, you need to run a command as part of your deploy step. This should be run as part of each deployment to ensure that the cache is being populated with each build's data. +In order for the cache to be properly initialized with the build-time revalidation data, you need to run a command as part of your deploy step. This should be run as part of each deployment to ensure that the cache is being populated with each build's data. To populate remote bindings and deploy your application at the same time, you can use the `deploy` command. Similarly, the `preview` command will populate your local bindings and start a Wrangler dev server. diff --git a/pages/cloudflare/former-releases/0.6/get-started.mdx b/pages/cloudflare/former-releases/0.6/get-started.mdx index 5b1e9b0d..833f25b5 100644 --- a/pages/cloudflare/former-releases/0.6/get-started.mdx +++ b/pages/cloudflare/former-releases/0.6/get-started.mdx @@ -194,4 +194,4 @@ Either deploy via the command line: npm run deploy ``` -Or [connect a Github or Gitlab repository](https://developers.cloudflare.com/workers/ci-cd/), and Cloudflare will automatically build and deploy each pull request you merge to your production branch. +Or [connect a GitHub or GitLab repository](https://developers.cloudflare.com/workers/ci-cd/), and Cloudflare will automatically build and deploy each pull request you merge to your production branch. diff --git a/pages/cloudflare/get-started.mdx b/pages/cloudflare/get-started.mdx index 82b53696..92ce105e 100644 --- a/pages/cloudflare/get-started.mdx +++ b/pages/cloudflare/get-started.mdx @@ -230,4 +230,4 @@ Either deploy via the command line: npm run deploy ``` -Or [connect a Github or Gitlab repository](https://developers.cloudflare.com/workers/ci-cd/), and Cloudflare will automatically build and deploy each pull request you merge to your production branch. +Or [connect a GitHub or GitLab repository](https://developers.cloudflare.com/workers/ci-cd/), and Cloudflare will automatically build and deploy each pull request you merge to your production branch. diff --git a/pages/cloudflare/howtos/dev-deploy.mdx b/pages/cloudflare/howtos/dev-deploy.mdx index d3e6acc4..c655ccc3 100644 --- a/pages/cloudflare/howtos/dev-deploy.mdx +++ b/pages/cloudflare/howtos/dev-deploy.mdx @@ -61,7 +61,7 @@ Use the `build` command followed by either `deploy` or `upload` to deploy your l When running the `build` command locally, `.dev.vars` and [Next `.env` files](https://nextjs.org/docs/pages/building-your-application/configuring/environment-variables) might - override your configuration. It is preferreable to use a CD system as [Workers + override your configuration. It is preferable to use a CD system as [Workers Builds](https://developers.cloudflare.com/workers/ci-cd/builds/) to deploy your application for reproducible deployments. diff --git a/pages/cloudflare/howtos/env-vars.mdx b/pages/cloudflare/howtos/env-vars.mdx index 9ec2b046..b4877fdc 100644 --- a/pages/cloudflare/howtos/env-vars.mdx +++ b/pages/cloudflare/howtos/env-vars.mdx @@ -4,7 +4,7 @@ import { Callout } from "nextra/components"; This entry describe the most sensible way to handle your environment variables which works well both during local development and once your application is deployed to Cloudflare Workers. -On the Cloudflare platform, your environment variables can be stored in either ["Enviroment variables"](https://developers.cloudflare.com/workers/configuration/environment-variables/) or ["Secrets"](https://developers.cloudflare.com/workers/configuration/secrets/). The difference being that Secrets can not be read back from either the dashboard or the CLI after being created. +On the Cloudflare platform, your environment variables can be stored in either ["Environment variables"](https://developers.cloudflare.com/workers/configuration/environment-variables/) or ["Secrets"](https://developers.cloudflare.com/workers/configuration/secrets/). The difference being that Secrets can not be read back from either the dashboard or the CLI after being created. ### Local development diff --git a/pages/cloudflare/howtos/keep_names.mdx b/pages/cloudflare/howtos/keep_names.mdx index acd30149..947f94ef 100644 --- a/pages/cloudflare/howtos/keep_names.mdx +++ b/pages/cloudflare/howtos/keep_names.mdx @@ -7,7 +7,7 @@ enables the [`keep-names`](https://esbuild.github.io/api/#keep-names) option. Wh cause issues with certain Next.js libraries (e.g. [next-themes](https://www.npmjs.com/package/next-themes)) that convert scripts to strings. This happens because `esbuild` introduces a `__name` function at the top of modules, which may inadvertently appear in the generated script strings. When these strings are evaluated at runtime, the `__name` function might therefore not be defined, -leading to errors logged in the developper console: +leading to errors logged in the developer console: ``` Uncaught ReferenceError: __name is not defined diff --git a/pages/cloudflare/howtos/multi-worker.mdx b/pages/cloudflare/howtos/multi-worker.mdx index 816402fc..e7964d2a 100644 --- a/pages/cloudflare/howtos/multi-worker.mdx +++ b/pages/cloudflare/howtos/multi-worker.mdx @@ -246,7 +246,7 @@ The steps to deploy without causing downtime to the already deployed ones are as 9. You then deploy the middleware at 100% `wrangler versions deploy @100% -y --config ./path-to/middlewareWrangler.jsonc`. At this stage you are already serving the new version of the website in production. 10. To finish it off you deploy the server at 100% `wrangler versions deploy @100% -y --config ./path-to/server-wrangler.jsonc`. -You can find actual implementations of such a deployment in the GitBook repo using Github actions [here](https://github.com/GitbookIO/gitbook/blob/main/.github/composite/deploy-cloudflare/action.yaml). +You can find actual implementations of such a deployment in the GitBook repo using GitHub actions [here](https://github.com/GitbookIO/gitbook/blob/main/.github/composite/deploy-cloudflare/action.yaml). #### Version Affinity Explained diff --git a/pages/cloudflare/howtos/skew.mdx b/pages/cloudflare/howtos/skew.mdx index 749f7325..d13895a0 100644 --- a/pages/cloudflare/howtos/skew.mdx +++ b/pages/cloudflare/howtos/skew.mdx @@ -26,7 +26,7 @@ export default { // Maximum number of previous versions to use. // Optional, default to 20. maxNumberOfVersions: 20, - // Age of the oldest version to use (from the last deplyment date) + // Age of the oldest version to use (from the last deployment date) // Optional, default to 7 days. maxVersionAgeDays: 7, }, @@ -68,7 +68,7 @@ and the process' environment variables. If a variable is set in both places, the **Next config** -You must set a different `deploymentId` in your next config each time your app is deployed. You will get an error if the `deployementId` has already been used by a previous deployment. +You must set a different `deploymentId` in your next config each time your app is deployed. You will get an error if the `deploymentId` has already been used by a previous deployment. The cloudflare adapter exports a `getDeploymentId()` function that can be used to generate a unique deployment id. diff --git a/pages/cloudflare/perf.mdx b/pages/cloudflare/perf.mdx index 4e7e0c2a..d6703925 100644 --- a/pages/cloudflare/perf.mdx +++ b/pages/cloudflare/perf.mdx @@ -22,7 +22,7 @@ The Incremental cache is the store containing all the cached data (i.e. pages, ` You should use the Workers Static Assets based cache if your site is SSG. It is the fastest available option. Note that as Workers Static Assets are read-only, this option can not be used with revalidation. -When your app uses re-validation, use the R2 based store instead. We recommend the following settings to get the best perfomance: +When your app uses re-validation, use the R2 based store instead. We recommend the following settings to get the best performance: - use regional cache by wrapping the handler into `withRegionalCache(...)` - use the `long-lived` mode