Dyes 
IWhat version of Wrangler are you using?
JNot 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.
J@cloudflare/next-on-pagesIf you want to deploy a full-stack Next.js application, you should use Next.js' features
TIs there any way to force exclude files from the final bundle of a route? I'm trying to use
vercel.json
SThanks 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?
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?
Dall the changes I made are there in the commits I shared, besides those and
yarn installthis is my configuration
D
Dand I am using the v2 build image
D
D(but I think you were using that too)
D(PS: I also think I've also got a fix for it , but that might not work for your particular case 
)
, 
BWhat was the cause?
BI believe that error occurs in some specific context of the Next.js app
Dyes, I think it only happens when the
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-reproGitHub
Contribute to dario-piotrowicz/next-on-Pages-top-level-getRequestContext-bug-repro development by creating an account on GitHub.
Dbasically I think that the Next.js build process, imports the files and that triggers such the
getRequestContext calls to happen, but since you're in nodejs the context is not presentDthe 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 runtime config DI could very very easily fix it by making
getRequestContext just return undefinedMh.... it is quite problematic... I'm thinking that likely the only viable solution is to forbid the use of (and implement a nice error message that makes that clear)
getRequestContext from the top level (and implement a nice error message that makes that clear)DPS: 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 
BWhy 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
Dwell, in production it needs to be in the edge runtime because everything is (the
nodejs is not supported) technically it could work in the 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
getRequestContextand the
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 theprocess.envnodejsruntime (asnext devalso actually runs yournodejscode in a separate child process, making hacks very difficult to do without actually modifying the next dev server itself)
MAfter reading the comments above, what would be the current setup to be able to retrieve the env variables with
setupDevPlatform? It seems im having difficulty configuring a D1 database to work both locally and in production.
Ldoes this include next on pages?
Dbasically the
setupDevPlatform call can stay as is, what you need to change is getRequestContext and make sure that it is not being called as part of the route initialization (e.g. don't put getRequestContext()
Dyes, I do think so (but I could be wrong)
Lif it does it doesn’t seem to be working.
Doh.... ok sorry, I'll have to check with the team and/or play a bit with it myself
Lcheers, so far i have a site using next on pages with git. i enabled it about a week ago and have done multiple deploys since. still nothing shows in the analytics ui and i don’t see anything being added to the page’s head.
i’ve disabled and re-enabled and no change.
i’ve disabled and re-enabled and no change.
DI see, I'll have a look thanks for the info
MHmmmmm the
getRequestContext can't be called within an actions.ts due to edge runtime requirement. Gana have to find another way to populate data to a client component.
Ddo you get a bacon script in your page's body by any chance?
D
Dwhat about the rum http requests?
