In function folder

await fetch(NEXT_PUBLIC_NHOST_GRAPHQL_API

this will not work if defined in Production environment variables? Asking because

NEXT_PUBLIC_NHOST_GRAPHQL_API is not defined

got this error in production functions.

is it defined as an ENV var in both environments?

Probably should be

env.NEXT_PUBLIC_NHOST_GRAPHQL_API

I'm getting my butt kicked by TypeScript. I thought this was working fine a few days ago but now TS is throwing errors for this:

export const onRequestGet: PagesFunction<Env, "params", Data> = async ({ env, params }) => { ... }

I am now getting

Cannot find name 'PagesFunction'.ts(2304)

However, I've setup my

tsconfing.json

as follows per the

@cloudflare/workers-types

instructions:

{
  "compilerOptions": {
    "alwaysStrict": true,
    "esModuleInterop": true,
    "jsx": "react-jsx",
    "jsxImportSource": "preact",
    "moduleResolution": "node",
    "noImplicitAny": true,
    "noUncheckedIndexedAccess": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "resolveJsonModule": true,
    "strict": true,
    "target": "ES2020",
    "module": "CommonJS",
    "lib": [
      "ES2020"
    ],
    "types": [
      "@cloudflare/workers-types"
    ]
  },
  "include": [
    "dev/**/*",
    "src/**/*",
    "functions/**/*"
  ],
  "exclude": [
    "node_modules"
  ]
}

It's now just Visual Studio Code either. If I run

yarn tsc

, I get the following:

functions/api/images/[id].ts:9:28 - error TS2304: Cannot find name 'PagesFunction'.

9 export const onRequestGet: PagesFunction<
                             ~~~~~~~~~~~~~

functions/api/images/[id].ts:13:14 - error TS7031: Binding element 'env' implicitly has an 'any' type.

13 > = async ({ env, params }) => {
                ~~~

functions/api/images/[id].ts:13:19 - error TS7031: Binding element 'params' implicitly has an 'any' type.

13 > = async ({ env, params }) => {
                     ~~~~~~

Anyone have any ideas?

what version of workers-types is in your lockfile?

Thanks for the reply. That was the culprit! I had two different ones.

"@cloudflare/workers-types@^2.2.2":
  version "2.2.2"
  resolved "https://registry.yarnpkg.com/@cloudflare/workers-types/-/workers-types-2.2.2.tgz#1bced16bba801d7af987da835467545bb5cc7ac6"
  integrity sha512-kaMn2rueJ0PL1TYVGknTCh0X0x0d9G+FNXAFep7/4uqecEZoQb/63o6rOmMuiqI09zLuHV6xhKRXinokV/MY9A==

"@cloudflare/workers-types@^3.2.0":
  version "3.2.0"
  resolved "https://registry.yarnpkg.com/@cloudflare/workers-types/-/workers-types-3.2.0.tgz#df300466f5f8a03b205bdd533990017b0538496e"
  integrity sha512-y0+f7QeB5/fMMdU0wSwvBB18yE9kAD2s7Wben8a4uI4f/EJyE+eJrai5QO52Pq8EmWP0vRpKqZh0qU857WhY2A==

Now, I realize why this happened. I installed Miniflare as a dependency so I could load some fake data into my KV namespace for developing locally. Miniflare must have added the old version of

@cloudflare/workers-types

. Removing Miniflare (and the old types) did the trick. So, I'll have to use Miniflare a bit differently. Thanks so much!

Last week we requested a raise of the 100.000 requests/day limit, as this would potentially block us from releasing a prod version on CF pages. We are in no particular hurry as we still have to replace a few of our old PHP functions before are able to switch to the JAM stack, but I am guessing early January we should be ready for prod. Since this is a blocker, I'd like to resolve this early. If we are not eligible that's perfectly fine as well, but then we would probably need a different solution until pages-functions is out of BETA. So I am wondering, how long does it usually take to get an answer?

Hey there - private messaging you

Is there any supported way to use some package management with pages-functions to support installing and managing 3rd party libraries?

Using middleware (https://developers.cloudflare.com/pages/platform/functions#middleware-routing)

├── functions
│   ├── _middleware.ts        # Applies to all routes
│   ├── ...
│   └── todos
│       ├── _middleware.ts    # Adds extra middleware to /todos/**
│       ├── ...
└── ...

I assumed the order of execution was top level first, deeper level next. I have an errorHandler on the top level, but it's executing first the inner middleware. Any idea why could that be? Using wrangler pages dev (alpha)

im using wrangler pages dev (alpha) and my middleware is executing top down, as you expect. One thing to check is that you are using the

return await next()

in both spots. If your top level isn't awaiting next, it might cause the behavior you are seeing.

Weird. I do have

return await next()

in both. But I have them as in the example using arrays:

//top level
export const onRequest = [
  errorHandler,
]

//next level
export const onRequest = [
  secondMiddleware,
]

Maybe that affects the awating? I'll try move it around

Nah, that's not it.

Mine setup is pretty simple, ill post my middlewares here in full

Top Level

import {setup as kvsetup } from './lib/global/KV'

const errorHandler = async ({ next }) => {
    try {
        console.log('before errorHandler')
        return await next()
    } catch (err) {
        return new Response(`${err.message}\n${err.stack}`, { status: 500 })
    }
}

const setup = async({env, next}) => {
    kvsetup(env)
    return await next()
}

export const onRequest = [
    errorHandler,
    setup
]

Level Down

const consoleHello = async ({ next }) => {
    try {
        console.log('hello from api middleware')
        return await next()
    } catch (err) {
        return new Response(`${err.message}\n${err.stack}`, { status: 500 })
    }
}

export const onRequest = [
    consoleHello
]

My console prints out the top level console log of the top level first and the lower level second

I just copy pasted your example and I get:

hello from api middleware
before errorHandler
actual endpoint

Just to be clear:

├── functions
│   ├── _middleware.ts        # THIS ONE IS TOP LEVEL (before errorHanlder)
│   ├── ...
│   └── todos
│       ├── _middleware.ts    # THIS IS DEEP LEVEL (hello from api middleware)
│       ├── ...
└── ...

Huh, here is mine after i added a console.log to the actual endpoint

before errorHandler
hello from api middleware
actual endpoint

Yes, that is how I have it set up

😖

Ni idea then. I'll update the wrangler to the latest alpha (I did it yesterday)

when did you install wrangler@Alpha ?

Yeah, i installed yesterday too

Just updated it (0.0.0-ae4fe86), same result 😦

I dont think it should matter but my files are .js not .ts

I wouldn't expect that to make a difference either

I think I found it. Seems like a bug in wrangler, could you try it? I have in a second level, so not like I was saying:

├── functions
│   ├── _middleware.ts        # THIS ONE IS TOP LEVEL (before errorHanlder)
│   ├── ...
│   └── todos
│       ├── _middleware.ts    # THIS IS DEEP LEVEL (hello from api middleware)
│       ├── ...
└── ...

But as:

├── functions
|    |-- api/
│       ├── _middleware.ts        # THIS ONE IS TOP LEVEL (before errorHanlder)
│       ├── ...
│       └── todos
│           ├── _middleware.ts    # THIS IS DEEP LEVEL (hello from api middleware)
│           ├── ...
└── ...

That way middlewares get inverted

Now i get:

hello from api middleware
before errorHandler
actual endpoint, hey

Just like you