I've forked your github repository (it should be this one right? https://github.com/satyam73/skill-t

I've forked your github repository (it should be this one right? https://github.com/satyam73/skill-tree-frontend)

and tried deploying the application, after a few minor adjustments it seems to work as expected:
https://c3f337ae.skill-tree-frontend-7zq.pages.dev/

(if it helps this is my fork: https://github.com/dario-piotrowicz/skill-tree-frontend)

Could you locally run

yarn install

yarn install

yarn install

yarn install to update the lock file, push the change and try again?
If it doesn't work please try to apply these changes to your repository: https://github.com/satyam73/skill-tree-frontend/compare/develop...dario-piotrowicz:skill-tree-frontend:develop

DarioOP•3/8/24, 7:17 PM

oh... I was on the developdevelop branch, let me try mainmain....

DarioOP•3/8/24, 7:26 PM

it seems like what I said above still applies on mainmain: https://github.com/dario-piotrowicz/skill-tree-frontend/tree/main
(https://main.skill-tree-frontend-7zq.pages.dev/)

(changes I made: https://github.com/satyam73/skill-tree-frontend/compare/main...dario-piotrowicz:skill-tree-frontend:main)

bun•3/9/24, 1:14 AM

what is the recommended way of initializing a database with drizzle for example in app router?

I'm trying to initialize it in src/server/db.tssrc/server/db.ts
with the following approach:

"use server";

import { getRequestContext } from "@cloudflare/next-on-pages";
import { Repository, getDB } from "@my-separate-package/db";

export const db = getDB(getRequestContext().env.DB ?? process.env.DB);

export const repository = new Repository(db);

"use server";

import { getRequestContext } from "@cloudflare/next-on-pages";
import { Repository, getDB } from "@my-separate-package/db";

export const db = getDB(getRequestContext().env.DB ?? process.env.DB);

export const repository = new Repository(db);

bun•3/9/24, 1:15 AM

but im getting ▲ Error: Failed to retrieve the Cloudflare request context.▲ Error: Failed to retrieve the Cloudflare request context. error when doing a next buildnext build. it works fine in development

bun•3/9/24, 1:22 AM

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

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 ...

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

@bun If you use the latest betabeta release you can just use process.env.DBprocess.env.DB both in development and production (process.envprocess.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.envprocess.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 ...

DarioOP•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-handlerkv-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 publicpublic folder.
Suppose my pages is deployed on example.comexample.com with a static file favicon.icofavicon.ico.
I used service binding in the same app which tries to fetch example.com/favicon.icoexample.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...

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

do you still need a reproduction ?

Bbun do you still need a reproduction ?

DarioOP•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.jsonvercel.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...

DarioOP•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

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

this is my configuration

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

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

and I am using the v2 build image

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

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

(but I think you were using that too)

Bbun do you still need a reproduction ?

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

@bun no I've got it

DarioOP•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~~ )

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

What was the cause?

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

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

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

yes, I think it only happens when the getRequestContextgetRequestContext 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.

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

basically I think that the Next.js build process, imports the files and that triggers such the getRequestContextgetRequestContext calls to happen, but since you're in nodejs the context is not present

DarioOP•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 edgeedge runtimeruntime config

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

I could very very easily fix it by making getRequestContextgetRequestContext just return undefinedundefined 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...

DarioOP•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 getRequestContextgetRequestContext from the top level

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

DarioOP•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

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

do you have any opinion on this @bun?

bun•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...

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

well, in production it needs to be in the edge runtime because everything is (the nodejsnodejs is not supported) technically it could work in the nodejsnodejs 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 getRequestContextgetRequestContext and the process.envprocess.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 nodejsnodejs runtime (as next devnext dev also actually runs your nodejsnodejs code in a separate child process, making hacks very difficult to do without actually modifying the next dev server itself)

I've forked your github repository (it should be this one right? https://github.com/satyam73/skill-t

Similar Threads