Releases: cloudflare/next-on-pages
@cloudflare/next-on-pages@1.11.1
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.
eslint-plugin-next-on-pages@1.11.0
Minor Changes
-
702f601: add new
no-app-nodejs-dynamic-ssg
ruleadd the new
no-app-nodejs-dynamic-ssg
rule that makes sure that
developers usinggenerateStaticParams
also export either theruntime
variable set toedge
or thedynamicParams
one set tofalse
-
82aa1a4: add new
no-pages-nodejs-dynamic-ssg
ruleadd the new
no-pages-nodejs-dynamic-ssg
rule that makes sure that
developers usinggetStaticPaths
set thefallback
property tofalse
or opt in into theedge
runtime
@cloudflare/next-on-pages@1.11.0
Patch Changes
-
555b4a7: fix
trailingSlash
set totrue
alongsidei18n
enabled causing incorrect404
s -
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 (innext-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
eslint-plugin-next-on-pages@1.10.0
eslint-plugin-next-on-pages@1.10.0
@cloudflare/next-on-pages@1.10.0
Minor Changes
-
739e2a7: make (no-op)
caches
available in dev modeupdate
setupDevPlatform
to also add acaches
object to the global scope
so that it can be used during development in a production-like mannernote: the implementation of
caches
is currently a no-op one
Patch Changes
-
90e140c: Make the
getRequestContext
's error message more helpful during local developmentDuring local development add information in the
getRequestContext
's error
message reminding the user to setup the dev platform viasetupDevPlatform
in their config file -
5187973: Make
getRequestContext
andgetOptionalRequestContext
throw if used inside the Node.js runtimeCurrently if users run
getRequestContext
orgetOptionalRequestContext
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.
eslint-plugin-next-on-pages@1.9.0
eslint-plugin-next-on-pages@1.9.0
@cloudflare/next-on-pages@1.9.0
Minor Changes
-
5712c57: Add new
getRequestContext
utilityIntroduce a new
getRequestContext
utility that allows developer to get access not only
to their Cloudflareenv
but also to theircf
andctx
objectsThe 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 deprecatingsetupDevBindings
Previously developers would provide their bindings as inline options passed to
thesetupDevBindings
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'swrangler.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 thewrangler.toml
file, making users
only need to declare the bindings at most once for local development instead of twice
- consistent with the newly introduced
eslint-plugin-next-on-pages@1.8.6
eslint-plugin-next-on-pages@1.8.6
@cloudflare/next-on-pages@1.8.6
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 afetch
event to the Worker containing the target Durable Object, not the Durable Object itself. This change ensures thefetch
event is dispatched directly to the Durable Object. -
3dd1f20: indent
setupDevBindings
warnings -
519c6cc: add
databaseId
variant for D1s to thesetupDevBindings
D1 binding typeD1 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
adatabaseId
field instead of thedatabaseName
for the binding and we present a warning
to users if thedatabaseName
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
miniflare@3.20231218.1
eslint-plugin-next-on-pages@1.8.5
eslint-plugin-next-on-pages@1.8.5