Skip to content

Releases: cloudflare/next-on-pages

@cloudflare/[email protected]

30 Apr 22:10
1493f82
Compare
Choose a tag to compare

Patch Changes

  • 31c2627: update package.json to properly export the typescript types

    the current types are declared in the package.json via typesVersions
    such don't seem to get picked up correctly by all package managers, to for
    the types use the package.json exports field instead

  • 31c2627: fix the setupDevPlatform's options parameter not being optional

[email protected]

23 Apr 12:20
beec78a
Compare
Choose a tag to compare

@cloudflare/[email protected]

23 Apr 12:20
beec78a
Compare
Choose a tag to compare

Patch Changes

  • f7bf30b: Ignore the invalid *.action.func folders introduced in next.js 14.2.2
  • 446e9af: exit with exit status 1 on build unexpected errors (when watch mode is disabled)
  • 5170477: Respect next basePath when configuring _next/static headers.
  • ad4ca02: Convert dynamic requires for cloudflare:* built-ins to import statements.
  • ad4ca02: Mark cloudflare:* as external for esbuild.

[email protected]

22 Mar 20:45
64988ca
Compare
Choose a tag to compare

Minor Changes

  • 702f601: add new no-app-nodejs-dynamic-ssg rule

    add the new no-app-nodejs-dynamic-ssg rule that makes sure that
    developers using generateStaticParams also export either the runtime
    variable set to edge or the dynamicParams one set to false

  • 82aa1a4: add new no-pages-nodejs-dynamic-ssg rule

    add the new no-pages-nodejs-dynamic-ssg rule that makes sure that
    developers using getStaticPaths set the fallback property to false
    or opt in into the edge runtime

@cloudflare/[email protected]

22 Mar 20:45
64988ca
Compare
Choose a tag to compare

Patch Changes

  • 555b4a7: fix trailingSlash set to true alongside i18n enabled causing incorrect 404s

  • 8da9da2: Make sure protocol relative URLs are not treated as actual relative URLs

  • 60eb0ae: fix issue in which redirect responses become rewrites when a middleware is involved

  • c3fb67b: make sure that the original request headers are not passed along when fetching external images

  • 9900517: fix process.env not giving access to bindings during local development (in next-dev)

  • 869cee0: Throw a user friendly error message when getRequestContext is called during prerendering

  • 53cb762: fix applications using Next.js v.14.2.0-canary.18 and up

    In v.14.2.0-canary.18 a simple upstream change in Next.js changes the code that
    next-on-pages receives, nullifying a find-and-replace regex that next-on-pages
    is currently relying on, update such regex so that it can handle the new code

[email protected]

04 Mar 12:30
46e53ec
Compare
Choose a tag to compare

@cloudflare/[email protected]

04 Mar 12:30
46e53ec
Compare
Choose a tag to compare

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]

13 Feb 18:13
687a39c
Compare
Choose a tag to compare

@cloudflare/[email protected]

13 Feb 18:13
687a39c
Compare
Choose a tag to compare

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]

31 Jan 10:12
52499eb
Compare
Choose a tag to compare