compatibility_flags = ["nodejs_compat"]

NobOP•3/30/24, 10:52 AM

in wrangler.toml too

thanhle•3/30/24, 10:57 AM

this 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:

thanhle•3/30/24, 10:57 AM

thanhle•3/30/24, 10:58 AM

thanhle•3/30/24, 10:59 AM

the second image is from Prisma docs, they also mention pg currently not work on next-on-pages

NobOP•3/30/24, 10:59 AM

sad

NobOP•3/30/24, 10:59 AM

use D1

NNob have you added node_compat = true to the flags of the worker ?

thanhle•3/30/24, 10:59 AM

how do I do that in next-on-pages?

Tthanhle how do I do that in next-on-pages?

NobOP•3/30/24, 11:00 AM

seem like the lib isnt compatible so dont need to test

NobOP•3/30/24, 11:01 AM

you can use D1 as a DB if you want SQL database

NNob use D1 👌

thanhle•3/30/24, 11:02 AM

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

Tthanhle actually I use AWS Lambda for fetching data cause I test the the backend with aw...

NobOP•3/30/24, 11:02 AM

have you enabled smart placement ?

thanhle•3/30/24, 11:03 AM

i try but it said that my worker does not make enough subrequest.

NNob compatibility_flags = ["nodejs_compat"]

Hello, I’m Allie!•3/30/24, 11:03 AM

You should only be using node_compat or nodejs_compat, not both

HHello, I’m Allie!You should only be using node_compat **or** nodejs_compat, not both

thanhle•3/30/24, 11:03 AM

yes. next-on-pages use nodejs compact and pg use node compact. so maybe they dont like each other

HHello, I’m Allie!You should only be using node_compat **or** nodejs_compat, not both

NobOP•3/30/24, 11:05 AM

I only use nodejs_compat

Tthanhle yes. next-on-pages use nodejs compact and pg use node compact. so maybe they don...

Dario•3/30/24, 11:05 AM

yes nodejs_compat and node_compat are indeed incompatible

(there's some work being made to make them compatible soon-ish)

DDario yes nodejs_compat and node_compat are indeed incompatible 🥲 (there's some work...

Hello, I’m Allie!•3/30/24, 11:05 AM

Oh, I thought it was to remove the need for node_compat at all?

Hello, I’m Allie!•3/30/24, 11:06 AM

So that everything would be under nodejs_compat

DDario yes nodejs_compat and node_compat are indeed incompatible 🥲 (there's some work...

thanhle•3/30/24, 11:09 AM

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

Dario•3/30/24, 11:09 AM

@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

DDario <@459755459117711362> yeah I thought that too, but my current understanding is t...

NobOP•3/30/24, 11:10 AM

why not separating nodejs_compat in multiples flags

NobOP•3/30/24, 11:10 AM

so you only add what functions you use

NobOP•3/30/24, 11:11 AM

like ["nodejs_asset", "nodejs_Crypto", etc]

Tthanhle Click to see attachment

NobOP•3/30/24, 11:12 AM

pg lib should use node:module but its not in the screen you sent

NobOP•3/30/24, 11:12 AM

NobOP•3/30/24, 11:13 AM

maybe you can configure webpack to change these imports

NNob like ["nodejs_asset", "nodejs_Crypto", etc]

Hello, I’m Allie!•3/30/24, 11:13 AM

That would just make it more confusing for people using a framework, if said framework needs ten different modules

HHello, I’m Allie!That would just make it more confusing for people using a framework, if said fra...

NobOP•3/30/24, 11:14 AM

or some static analysis on your code that guess what you are using (gonna be nightmare)

DDario <@459755459117711362> yeah I thought that too, but my current understanding is t...

Hello, I’m Allie!•3/30/24, 11:14 AM

Isn't that what nodejs_compatnodejs_compat is already? Under the hood, they may not be exactly what Node does, but if the input/output are the same, then aren't those modules/polyfills already being supported perpetually?

NNob why not separating nodejs_compat in multiples flags

Dario•3/30/24, 11:15 AM

I guess that would be possible, but what would be the benefit of it?

DDario I guess that would be possible, but what would be the benefit of it? 😮

NobOP•3/30/24, 11:16 AM

performance, idk if there is some performance gain if we dont use nodejs_compat but probably

NNob performance, idk if there is some performance gain if we dont use nodejs_compat ...

Hello, I’m Allie!•3/30/24, 11:18 AM

Not really. All of nodejs_compatnodejs_compat is already built into the runtime, so the flag only determines whether you actually have access to it or not.

Hello, I’m Allie!•3/30/24, 11:18 AM

You 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

NobOP•3/30/24, 11:19 AM

@thanhle

NobOP•3/30/24, 11:19 AM

try adding this into the nextjs config

NobOP•3/30/24, 11:19 AM

    webpack: (config, { isServer }) => {
        config.resolve.alias = {
            ...config.resolve.alias,
            path: 'node:path',
            fs: 'node:fs',
            stream: 'node:stream',
        };

        return config;
    }

    webpack: (config, { isServer }) => {
        config.resolve.alias = {
            ...config.resolve.alias,
            path: 'node:path',
            fs: 'node:fs',
            stream: 'node:stream',
        };

        return config;
    }

HHello, I’m Allie!Isn't that what `nodejs_compat` is already? Under the hood, they may not be *exa...

Dario•3/30/24, 11:22 AM

yes 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

NNob performance, idk if there is some performance gain if we dont use nodejs_compat ...

Dario•3/30/24, 11:23 AM

nah, 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

DDario yes that's true, what I was saying is that for some modules (the most used and t...

Hello, I’m Allie!•3/30/24, 11:23 AM

Wouldn'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_compatnode_compat?

Hello, I’m Allie!•3/30/24, 11:24 AM

It just seems kind of confusing to have node_compatnode_compat and nodejs_compatnodejs_compat, especially if you don't work with Workers/Pages often/this is your first experience with the platform.

HHello, I’m Allie!Wouldn't another solution be to pressure the packages people use that require th...

Dario•3/30/24, 11:26 AM

Wouldn'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)

HHello, I’m Allie!It just seems kind of confusing to have `node_compat` and `nodejs_compat`, espec...