@cloudflare/[email protected]

Minor Changes

• 739e2a7: make (no-op) caches available in dev mode

  update setupDevPlatform to also add a caches object to the global scope
  so that it can be used during development in a production-like manner

  note: the implementation of caches is currently a no-op one

Patch Changes

• 90e140c: Make the getRequestContext's error message more helpful during local development

  During local development add information in the getRequestContext's error
  message reminding the user to setup the dev platform via setupDevPlatform
  in their config file

• 5187973: Make getRequestContext and getOptionalRequestContext throw if used inside the Node.js runtime

  Currently if users run getRequestContext or getOptionalRequestContext in the Node.js runtime
  they get a generic error saying that the request context could not be found, improve such behavior
  by having the functions throw instead, clearly informing the user that the problem is the wrong
  runtime being used

• 9b1d951: Fix bundled wasm imports that are not located inside the function's directory.

• b46977c: Fix the Next.js originalRequest bug for an unminified edge function generated by Vercel.

[email protected]

[email protected]

@cloudflare/[email protected]

Minor Changes

• 5712c57: Add new getRequestContext utility

  Introduce a new getRequestContext utility that allows developer to get access not only
  to their Cloudflare env but also to their cf and ctx objects

  The utility can only be used in server-only code (meaning that it is incompatible with
  Pages-router components).

  Usage example:

  // app/api/hello/route.js
  
  import { getRequestContext } from '@cloudflare/next-on-pages';
  
  export const runtime = 'edge';
  
  export async function GET(request) {
    const {
      env,
      cf,
      ctx: { waitUntil },
    } = getRequestContext();
    // ...
  }

• 06de52e: add new setupDevPlatform while deprecating setupDevBindings

  Previously developers would provide their bindings as inline options passed to
  the setupDevBindings function (see: https://github.com/cloudflare/next-on-pages/tree/main/internal-packages/next-dev#how-to-use-the-module)

  Such function has been deprecated and the new setupDevPlatform has been added instead as its replacement, the latter does not
  require users to use inline options but it reads and gathers the binding definitions from the user's wrangler.toml file instead,
  this is:

  • consistent with the newly introduced getBindingsProxy utility (which is actually being used here under the hood)
    (https://developers.cloudflare.com/workers/wrangler/api/#getbindingsproxy)
  • more convenient for users, since wrangler pages dev is also going to read the wrangler.toml file, making users
    only need to declare the bindings at most once for local development instead of twice

[email protected]

[email protected]

@cloudflare/[email protected]

Patch Changes

• 0b1af18: add assertions for making sure that the required setupDevBindings options are provided

• bb18e8a: fix: ensure Durable Object stub proxies fetch Durable Objects and not their containing Worker

  Previously, calling DurableObjectStub#fetch() would dispatch a fetch event to the Worker containing the target Durable Object, not the Durable Object itself. This change ensures the fetch event is dispatched directly to the Durable Object.

• 3dd1f20: indent setupDevBindings warnings

• 519c6cc: add databaseId variant for D1s to the setupDevBindings D1 binding type

  D1 databases can only be referenced by their ID and not name, the current implementation
  wrongly accepts the database name and uses it as the database id, in order to amend this
  without introducing a breaking change we add a variant of the D1 binding type that accepts
  a databaseId field instead of the databaseName for the binding and we present a warning
  to users if the databaseName is used instead.

  When a better more stable/clear API will be decided for D1 bindings we can revisit this API.

• 05b6256: remove the invalid stringification of var bindings in next-dev

• bb18e8a: chore: bump to [email protected]

[email protected]

[email protected]

@cloudflare/[email protected]

Patch Changes

• ea73acc: fix variables not getting recorded correctly in next-dev

@cloudflare/[email protected]

Patch Changes

• f07ea9b: Update the next-dev's setupDevBindings API and remove the module's __experimental__ prefix

[email protected]

Patch Changes

• ed9a4ac: remove the no-longer-necessary no-app-not-found-runtime rule in a backward compatible manner

• 72426c2: update no-unsupported-configs with new configs options

  in the no-unsupported-configs rule handle the following new options:

  • logging
  • optimizePackageImports
  • ppr (Partial Prerendering)
  • serverActions

@cloudflare/[email protected]

Patch Changes

• a4efc7b: ignore invalid _error functions in the App router

  In the App router, error boundaries are implemented as client components (see: https://nextjs.org/docs/app/api-reference/file-conventions/error),
  meaning that they should not produce server side logic.

  The Vercel build process can however generate _error.func lambdas (as they are useful in the
  Vercel network I'd assume), through experimentation we've seen that those do not seem to be
  necessary when building the application with next-on-pages so they should be safe to ignore.

  The changes here make such invalid _error.func lambdas (if present) ignored (as they would otherwise
  cause the next-on-pages build process to fail)

• 352bf4b: Make route matching check handle better trailing slashes

  Currently having trailingSlash set to true in the next.config.js file
  results in some routes not being correctly handled, this fix addresses such
  issue