ok. `process.env.NODE_ENV === "development" ? getRequestContext().env.DB : (process.env as a

ok.

process.env.NODE_ENV === "development"
    ? getRequestContext().env.DB
    : (process.env as any).DB

process.env.NODE_ENV === "development"
    ? getRequestContext().env.DB
    : (process.env as any).DB

process.env.NODE_ENV === "development"
    ? getRequestContext().env.DB
    : (process.env as any).DB

process.env.NODE_ENV === "development"
    ? getRequestContext().env.DB
    : (process.env as any).DB

works

Deo Kumar•3/9/24, 3:14 AM

I am using service bindings in my application, fetching assets in workers leads to 522 response code. Is there any way to fetch static assets from workers on same origins?

Bbun ok. `process.env.NODE_ENV === "development" ? getRequestContext().env.DB ...

Dario•3/9/24, 12:57 PM

@bun If you use the latest

beta

beta

release you can just use

process.env.DB

process.env.DB

both in development and production (

process.env

process.env

not working in development was a bug I've fixed here: https://github.com/cloudflare/next-on-pages/pull/690)

ideally devs should always use

getRequestContext()

getRequestContext()

and not

process.env

process.env

, but it seems like

getRequestContext()

getRequestContext()

has some bug that makes it not work in some cases, I'll definitely look into that the only thing is that I haven't gotten a minimal reproduction to play with that till now (I did briefly tried to reproduce it with no luck, I should also try that again if I can't get a minimal repro)

(PS: if you do have a reproduction that you can share please throw it my way!

)

DDeo Kumar I am using service bindings in my application, fetching assets in workers leads ...

Dario•3/9/24, 1:00 PM

can you share your code? how are you trying to fetch your assets? have you tried with

kv-asset-handler

kv-asset-handler

? (https://github.com/cloudflare/workers-sdk/tree/main/packages/kv-asset-handler)

Deo Kumar•3/9/24, 1:37 PM

I want to fetch the static assets in

public

public

folder.
Suppose my pages is deployed on

example.com

example.com

with a static file

favicon.ico

favicon.ico

.
I used service binding in the same app which tries to fetch

example.com/favicon.ico

example.com/favicon.ico

.

I need to fetch images files uploaded on pages after build for optimisation using wasm

Deo Kumar•3/9/24, 1:40 PM

The worker fetches files if routed to different origin but respond with 522 when same origin.

Deo Kumar•3/9/24, 1:47 PM

https://fineshop.app/api/image?url=https://fineshop.app/logos/logo-512x512.png&w=256&q=75

https://image.fineshopdesign.workers.dev/image?url=https://fineshop.app/logos/logo-512x512.png&w=256&q=75

First one using service bindings but same workers.

DDario <@1068666142610161725> If you use the latest `beta` release you can just use `pr...

bunOP•3/9/24, 6:29 PM

do you still need a reproduction ?

Bbun do you still need a reproduction ?

Dario•3/9/24, 6:45 PM

yes

Isaac McFadyen•3/9/24, 9:22 PM

What version of Wrangler are you using?

James•3/9/24, 9:23 PM

Not sure what you're referring to. The Next.js docs are pretty clear about how API routes are written. Your screenshot above looks like a Pages function, not a Next.js API route, and next-on-pages only supports Next.js, not the functions directory.

James•3/9/24, 9:30 PM

@cloudflare/next-on-pages

@cloudflare/next-on-pages

is for deploying full-stack Next.js apps to Cloudflare Pages. Therefore, you should be using native Next.js features. The functions directory will not work with next-on-pages because we have our own worker to handle your requests. If you want to use the functions directory, you won't be able to use next-on-pages

James•3/9/24, 9:35 PM

https://developers.cloudflare.com/pages/framework-guides/nextjs/deploy-a-nextjs-site

James•3/9/24, 9:42 PM

If you want to deploy a full-stack Next.js application, you should use Next.js' features

TravisFrank•3/10/24, 3:53 PM

Is there any way to force exclude files from the final bundle of a route? I'm trying to use

vercel.json

vercel.json

, but it doesn't seem to be working :/

DDario I've forked your github repository (it should be this one right? https://github....

Satyam Bajpai•3/10/24, 6:13 PM

Thanks for putting this much efforts @Dario

Really appreciate your efforts

Could you please tell me what configuration you choose while deploying?

Also, for me, when I am running yarn install in local the changes aren't coming in yarn.lock file and in yours there are changes, so did you have done some other steps too?

SSatyam Bajpai Thanks for putting this much efforts <@691072002806513684> 🫡❤️🙌✨ Really appre...

Dario•3/10/24, 6:26 PM

all the changes I made are there in the commits I shared, besides those and

yarn install

yarn install

, I didn't do anything else

Dario•3/10/24, 6:26 PM

this is my configuration

Dario•3/10/24, 6:26 PM

Dario•3/10/24, 6:26 PM

and I am using the v2 build image

Dario•3/10/24, 6:26 PM

Dario•3/10/24, 6:26 PM

(but I think you were using that too)

Bbun do you still need a reproduction ?

Dario•3/10/24, 11:19 PM

@bun no I've got it

Dario•3/10/24, 11:21 PM

(PS: I also think I've also got a fix for it

, ~~but that might not work for your particular case~~ )

bunOP•3/11/24, 1:43 PM

What was the cause?

bunOP•3/11/24, 1:43 PM

I believe that error occurs in some specific context of the Next.js app

Dario•3/11/24, 5:37 PM

yes, I think it only happens when the

getRequestContext

getRequestContext

is part of the top-level scope of a file, as you can see here: https://github.com/dario-piotrowicz/next-on-Pages-top-level-getRequestContext-bug-repro

GitHub

GitHub - dario-piotrowicz/next-on-Pages-top-level-getRequestContext...

Contribute to dario-piotrowicz/next-on-Pages-top-level-getRequestContext-bug-repro development by creating an account on GitHub.

Dario•3/11/24, 5:38 PM

basically I think that the Next.js build process, imports the files and that triggers such the

getRequestContext

getRequestContext

calls to happen, but since you're in nodejs the context is not present

Dario•3/11/24, 5:41 PM

the annoying bit is also that prerendering does not work with files using the edge runtime so those calls not working is not something that should really cause issues, but naturally Next.js does need to import those files in order to see if they are exporting the

edge

edge

runtime

runtime

config

Dario•3/11/24, 5:42 PM

I could very very easily fix it by making

getRequestContext

getRequestContext

just return

undefined

undefined

during prerendering, but if there is other code that on the top level uses such bindings it could be problematic, so I'll have to experiment and think about it a bit...

Dario•3/11/24, 6:58 PM

Mh.... it is quite problematic... I'm thinking that likely the only viable solution is to forbid the use of

getRequestContext

getRequestContext

from the top level

(and implement a nice error message that makes that clear)

Dario•3/11/24, 7:01 PM

PS: trying to use it alongside bindings top-level does seem to also cause hydration problems, so maybe forbidding it altogether is indeed the right choice

Dario•3/11/24, 7:01 PM

do you have any opinion on this @bun?

bunOP•3/11/24, 7:14 PM

Why does getRequestContext require edge runtime specifically? Couldnt it just return undefined for cf and ctx, but provide bindings as they already somehow exist in process.env

Bbun Why does getRequestContext require edge runtime specifically? Couldnt it just re...

Dario•3/11/24, 9:22 PM

well, in production it needs to be in the edge runtime because everything is (the

nodejs

nodejs

is not supported) technically it could work in the

nodejs

nodejs

runtime during development but there are two major issues with that:

It wouldn't make too much sense, as it would allow people to use the utility when it's meaningless, I feel like that could add much more confusion than anything else
(e.g. why allow people to do something when that thing is not going to work in production anyways?)
the way in which both
```
getRequestContext
```
```
getRequestContext
```
and the
```
process.env
```
```
process.env
```
bindings work in dev mode is via this hack I came up with in which we can basically monkey patch the edge runtime context so that it the require data is made available there, I don't think there is such hack for the
```
nodejs
```
```
nodejs
```
runtime (as
```
next dev
```
```
next dev
```
also actually runs your
```
nodejs
```
```
nodejs
```
code in a separate child process, making hacks very difficult to do without actually modifying the next dev server itself)