have you added node_compat = true to the flags of the worker ?
have you added node_compat = true to the flags of the worker ?
Nand also here
Tyes I add there.
Ncompatibility_flags = ["nodejs_compat"]
Nin wrangler.toml too
Tthis is my setup: I have a nextjs page and I use the edge runtime with pg to fetch data from database and then deploy it to Cloudflare through Git intergration. this is the error I got when Cloudflare try to build the project through the dashboard:
T
T
Tthe second image is from Prisma docs, they also mention pg currently not work on next-on-pages
Nsad
Nuse D1 
Thow do I do that in next-on-pages?
Nseem like the lib isnt compatible so dont need to test
Nyou can use D1 as a DB if you want SQL database
Tactually I use AWS Lambda for fetching data cause I test the the backend with aws lambda and worker and found that server is close to database is better then server is close to user when you fetch database. the response time of aws lambda is two times faster than workers when fetching data from the database.
Nhave you enabled smart placement ?
Ti try but it said that my worker does not make enough subrequest.
HYou should only be using node_compat or nodejs_compat, not both
Tyes. next-on-pages use nodejs compact and pg use node compact. so maybe they dont like each other
NI only use nodejs_compat
Dyes nodejs_compat and node_compat are indeed incompatible 
(there's some work being made to make them compatible soon-ish)
(there's some work being made to make them compatible soon-ish)
HOh, I thought it was to remove the need for node_compat at all?
HSo that everything would be under nodejs_compat
Tbut I think the issue pg doesnot work with next-on-pages is because of the build time with webpack. I use the pg lib for Workers and it works really good.
D@Hello, I’m Allie! yeah I thought that too, but my current understanding is that we don't really want to put everything under nodejs_compat as that would introduce those modules/polyfills in the runtime, forcing us to basically support them forever and handle their updates/deprecation accordingly... so a bit of a burden 
So the solution is, I believe, to put under nodejs_compat as much as it makes sense but still have node_compat for the less stable polyfills, and make nodejs_compat and node_compat compabile
So the solution is, I believe, to put under nodejs_compat as much as it makes sense but still have node_compat for the less stable polyfills, and make nodejs_compat and node_compat compabile
Nwhy not separating nodejs_compat in multiples flags
Nso you only add what functions you use
Nlike ["nodejs_asset", "nodejs_Crypto", etc]
Npg lib should use node:module but its not in the screen you sent
N
Nmaybe you can configure webpack to change these imports
HThat would just make it more confusing for people using a framework, if said framework needs ten different modules
Nor some static analysis on your code that guess what you are using (gonna be nightmare)
HIsn't that what
nodejs_compatI guess that would be possible, but what would be the benefit of it? 
Nperformance, idk if there is some performance gain if we dont use nodejs_compat but probably
HNot really. All of
nodejs_compatYou could make an argument for having the flags as a way to pressure a framework to use less of them(making them more compliant with cross-platform standards), but not sure whether that would actually work
Ntry adding this into the nextjs config
NDyes that's true, what I was saying is that for some modules (the most used and the ones with the most stable polyfills), shipping them with the runtime makes sense, but for others no (like rarely used modules or ones with polyfills that are not stable/well maintained)
so I think the runtime team wants to strike the right balance there
so I think the runtime team wants to strike the right balance there
Dnah, I did ask the runtime team some time ago, it sounds like enabling or not the nodejs_compat flag does not have any performance downside, the only current real downside is the incompatibility with node_compat
HWouldn't another solution be to pressure the packages people use that require those modules to switch to something runtime agnostic? Or finding an alternative that doesn't require
node_compatIt just seems kind of confusing to have
node_compatnodejs_compatWouldn't another solution be to pressure the packages people use that require those modules to switch to something runtime agnostic?yes, for sure, but there's a lot of such packages, also many are not properly maintained and the maintainers are not interested in switching to something else (and aren't even willing to accept contributions from us)
Ni did not know it was 2 different things x)
DOr finding an alternative that doesn't require node_compat?that's practically the current situation, isn't it?
JThis is a Next.js build error and is completely out of our control
Dyes... I can't agree more, the two flags confused me for a while 
but hey... technical limitations are technical limitations
but hey... technical limitations are technical limitations
NI have a question, is it a good idea to have link prefetch enabled by default ?
