<@459755459117711362> yeah I thought that too, but my current understanding is that we don't really

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

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

why not separating nodejs_compat in multiples flags

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

so you only add what functions you use

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

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

Tthanhle Click to see attachment

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

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

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

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

Nob•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_compat

nodejs_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

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

Nob•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_compat

nodejs_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

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

@thanhle

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

try adding this into the nextjs config

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

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

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

node_compat

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

It just seems kind of confusing to have

node_compat

node_compat

and

nodejs_compat

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

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

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

i did not know it was 2 different things x)

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

Or finding an alternative that doesn't require node_compat?

that's practically the current situation, isn't it?

Tthanhle Click to see attachment

James•3/30/24, 11:28 AM

This is a Next.js build error and is completely out of our control

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

DarioOP•3/30/24, 11:28 AM

yes... I can't agree more, the two flags confused me for a while

but hey... technical limitations are technical limitations

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

I have a question, is it a good idea to have link prefetch enabled by default ?

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

I get like 30 worker executions per page just because nextjs like to prefetch everything

NNob I have a question, is it a good idea to have link prefetch enabled by default ?

James•3/30/24, 12:42 PM

I would say no personally, simply because of the amount of unnecessary requests it causes

JJames I would say no personally, simply because of the amount of unnecessary requests ...

Nob•3/30/24, 12:58 PM

i created a custom link component that set prefetch=false automatically, idk why nextjs enabled it by default

Nob•3/30/24, 12:58 PM

and I dont see a big difference in load time

James•3/30/24, 12:59 PM

the cynical view would be more requests = more money

James•3/30/24, 12:59 PM

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

JJames I understand the benefits behind prefetching, but I don't understand the need to...

Nob•3/30/24, 1:01 PM

yes but in nextjs you can either disable it completly (not even on hover) or enable for viewport

Nob•3/30/24, 1:08 PM

I think they do that because they will get more money from vercel

James•3/30/24, 1:11 PM

I never realised you couldn't have hover only. that sounds like a worthwhile feature to add

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

zegevlier•3/30/24, 1:15 PM

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

zegevlier•3/30/24, 1:15 PM

Please correct me if I'm wrong

James•3/30/24, 1:15 PM

I thought the plan was to get rid of the node_compat nonsense /shrug

DDario yes... I can't agree more, the two flags confused me for a while 😅 but hey......

Isaac McFadyen•3/30/24, 1:29 PM

Technical 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?

IIsaac McFadyen Technical limitations are technical limitations but naming them similar sounding...

DarioOP•3/30/24, 3:34 PM

again, I totally totally agree

historical reasons?!

Zzegevlier Does that not go against the backwards compatibility philosophy of workers? Putt...

DarioOP•3/30/24, 3:36 PM

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

Nob•3/30/24, 3:52 PM

How do i test my api routes db calls from local development, like accessing kv from next dev

DDario mh.... well, the "somewhere other than the runtime" is wrangler, since that is a...

zegevlier•3/30/24, 4:01 PM

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

Deo Kumar•3/30/24, 6:37 PM

Does blob: fetch not work on next on pages?
Like:

fetch(new URL("../noto-sans.ttf.bin", import.meta.url))

fetch(new URL("../noto-sans.ttf.bin", import.meta.url))

The above works in development mode but doesn't work when using npx wrangler pages dev

Deo Kumar•3/30/24, 6:38 PM

Also, I think this is the reason why @vercel/og doesn't work with next-on-pages?

DDeo Kumar Also, I think this is the reason why @vercel/og doesn't work with next-on-pages?

Nob•3/30/24, 9:52 PM

@vercel/og works with next-on-pages

Zzegevlier It would require you to stick with old, unsupported, versions of wrangler if you...

DarioOP•3/30/24, 11:18 PM

I see... the way I see it is sort of like: we don't have a perfect solution, so, instead of adding to the runtime something half-baked/problematic right now (thus committing to it forever) let's find an intermediate solution that can help people out to some degree, best-effort like. That being the build time node_compat flag.

That does make sense to me.

Also people with much more knowledge in that area than me made the decision above (which I don't know how set in stone is to be honest), people who know the downsides and maintenance burden of adding such polyfills into the runtime, so I trust their judgment

, but if you want I am totally happy to pass your feedback along or see if I can connect you directly with them

NNob @vercel/og works with next-on-pages

DarioOP•3/30/24, 11:20 PM

yeah it should!

(
although there's a small bug that makes it potentially fail sometimes

as you can see near the bottom here: https://github.com/cloudflare/next-on-pages/issues/39
)

GitHub

[🐛 Bug]: `@vercel/og` doesn't work · Issue #39 · cloudflare/next-on...

I'm having issues getting my project to successfully deploy on Cloudflare because I am relying on a dependency (@vercel/og) which uses satori/wasm. The Vercel building process goes fine but whe...

DDeo Kumar Does blob: fetch not work on next on pages? Like: ``` fetch(new URL("../noto-sa...

DarioOP•3/30/24, 11:21 PM

it should work...

(could you maybe share a repro?

)

Kimitri•3/31/24, 4:37 AM

I installed @cloudflare/next-on-pages on my aplication and it alert a lot of vulnerability

npm audit report

debug 4.0.0 - 4.3.0
Regular Expression Denial of Service in debug - https://github.com/advisories/GHSA-gxpj-cx7g-858c
fix available via npm audit fixnpm audit fix
node_modules/@vercel/fun/node_modules/debug
@vercel/fun <=1.1.0
Depends on vulnerable versions of debug
Depends on vulnerable versions of semver
node_modules/@vercel/fun
vercel 28.12.3 >=32.0.2
Depends on vulnerable versions of @vercel/fun
Depends on vulnerable versions of @vercel/node
node_modules/vercel

semver 7.0.0 - 7.5.1
Severity: moderate
semver vulnerable to Regular Expression Denial of Service - https://github.com/advisories/GHSA-c2qf-rxjj-qqgw
fix available via npm audit fixnpm audit fix
node_modules/@vercel/fun/node_modules/semver

undici <=5.28.2
Undici proxy-authorization header not cleared on cross-origin redirect in fetch - https://github.com/advisories/GHSA-3787-6prv-h9w3
fix available via npm audit fixnpm audit fix
node_modules/@vercel/node/node_modules/undici
@vercel/node 2.14.0 || >=3.0.2
Depends on vulnerable versions of undici
node_modules/@vercel/node

6 vulnerabilities (3 low, 3 moderate)

GitHub

CVE-2017-16137 - GitHub Advisory Database

Regular Expression Denial of Service in debug

GitHub

CVE-2022-25883 - GitHub Advisory Database

semver vulnerable to Regular Expression Denial of Service

GitHub

CVE-2024-24758 - GitHub Advisory Database

Undici proxy-authorization header not cleared on cross-origin redirect in fetch

<@459755459117711362> yeah I thought that too, but my current understanding is that we don't really

npm audit report

Similar Threads

npm audit report