You should only be using node_compat **or** nodejs_compat, not both
You 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 ?
NI get like 30 worker executions per page just because nextjs like to prefetch everything
JI would say no personally, simply because of the amount of unnecessary requests it causes
Ni created a custom link component that set prefetch=false automatically, idk why nextjs enabled it by default
Nand I dont see a big difference in load time
Jthe cynical view would be more requests = more money
JI understand the benefits behind prefetching, but I don't understand the need to prefetch everything in the viewpoint. on hover, sure, but not the viewport.
Nyes but in nextjs you can either disable it completly (not even on hover) or enable for viewport
NI think they do that because they will get more money from vercel
JI never realised you couldn't have hover only. that sounds like a worthwhile feature to add
ZDoes that not go against the backwards compatibility philosophy of workers? Putting it somewhere other than the runtime because that allows for breaking changes seems to me like trying to exploit a "loophole" in the rules around backwards compatibility.
ZPlease correct me if I'm wrong
JI thought the plan was to get rid of the node_compat nonsense /shrug
ITechnical limitations are technical limitations but naming them similar sounding (and same meaning things) when they're different doesn't really sound like a technical limitation? 
Dagain, I totally totally agree
historical reasons?!
historical reasons?!
Dmh.... well, the "somewhere other than the runtime" is wrangler, since that is a built time flag, and that is under semver... is that really a loophole? 
NHow do i test my api routes db calls from local development, like accessing kv from next dev
ZIt would require you to stick with old, unsupported, versions of wrangler if you want to make sure your worker keeps working as expected. The only reason I can see for not using compat dates is because you plan to break backwards compatibility at some point, and that feel very wrong to me in workers. While you are correct that this wouldn't technically violate the backwards compatibility guarantees (a change in this wouldn't be a change in the runtime, and deployed workers would keep working), it still doesn't sit right with me.
