Configuration file for Pages projects does not support "node_compat"
I'm having some compatability issues, where my code works on Workers but not on Pages Functions.
54 Replies
Hey. Pages doesn't support
node_compat, but it does support nodejs_compat, which is slightly different@Vero 🐙 will this help? https://x.com/jasnell/status/1795872787594358875
or it is only for Workers (not Pages Functions)
James M Snell (@jasnell) on X
A @Cloudflare Workers Node.js compatibility update... we will soon be enabling a revised version of the nodejs_compat flag (called nodejs_compat_v2) that makes a couple of key improvements to the implementation...
Twitter
functions are workers
so it's available for them too
but if it will help depends on your needs and what packages you require
knex is the package. and if they were the same thing, or functioned in the same way then node_compat flag would work the same as nodejs_compat
but they do not.Being the same doesn't mean the support is the same (long story)
Product explicitly decided to not support node_compat due to it being our not recommended thing
so then what is the solution? where this library works on Workers but not on Pages?
@Walshy | Deploying
https://github.com/jjjrmy/hono-sutando-cf-worker-pages
https://sutando-cf.dventures.workers.dev/users
https://sutando-cf.pages.dev/users
Pages Failed Deployment:
0c8ad5d4-69f0-46d3-98fe-81e3922b1bc3GitHub
GitHub - jjjrmy/hono-sutando-cf-worker-pages
Contribute to jjjrmy/hono-sutando-cf-worker-pages development by creating an account on GitHub.
?
was just responding with a reproduciton repo - so maybe someone on the Workers/Pages team can get to the bottom of it
Again, not supporting node_compat was an explicit decision, it was not done intentionally. It isn't a bug.
so then what do you do in a case like this? just not use Cloudflare?
Find an alternative library that does support edge runtimes.
if everything points to using Cloudflare Pages over Workers, but Pages doesn't support the same libraries
read the deploy log - it seems like it's a different limitation than the library itself
Error: Failed to publish your Function. Got error: Uncaught Error: Dynamic require of "events" is not supportedyou or a library is doing a dynamic require('events'). This isn't supported by esbuild (the Workers/Pages bundler that Wrangler uses).
then how is it working on Workers?
Though
events is another nodejs api that isn't in workers
you are clearly not doing this dynamic require when you did it with workersit's the same codebase
both those URLs above use the same repo
Ok. Well I said what the issue is.
so unless the action that deploys to Workers builds it differently, than idk?
https://github.com/cloudflare/wrangler-action
this seems like something else, not a Node issue?
This is almost certainly due to
node_compat in wrangler + Workers being legacy, and doing weird things injecting node-specific APIs like events. If I would to guess, that's what happening here in Workers, but with Functions, node_compat isn't used, and therefore that events require isn't being stubbed, and then fails at runtime.
nodejs_compat_v2 in compatibility_flags might work - I've not personally tested much with it yet, nor am certain if it includes events or not.
node_compat vs nodejs_compat is pretty confusing, but node_compat is thankfully being phased out so over time this should become much easier, especially now with the introduction of nodejs_compat_v2 which does fundemantally a lot of the same things, but without all the build-time hacks.I'm building it with _v2
lets see
14:26:22.477 Error: Failed to publish your Function. Got error: No such compatibility flag: experimental:nodejs_compat_v2
3080aa6b-e5e7-43cf-a946-25209966bcd7
is the deploymentI'd recommend you first test this running locally with
wrangler pages dev if you haven't already - it's going to be much faster for debuggingwell that error still stands
it seems like that command allowed it to build
just get this error locally:
even though it is
compatibility_flags = ["experimental:nodejs_compat_v2"]The flag is still pretty experimental so it's possible you're going to hit bugs/issues with it, especially in Pages where it's likely been less tested. I'd recommend creating a minimal reproduction and filing a wrangler issue if you determine there to be an issue here
where should I make the issue
that repo I linked is for the reproduction
the flag flat out doesn't work 🤷🏼♂️
https://github.com/cloudflare/workers-sdk would be the best place, but I'd showcase this without
node_compat. Pages doesn't support that intentionally, and almost certainly never willwhat?
the repo isn't using
node_compat=true, that's for the Workers deployment
@James maybe this needs to be enabled on my account?It’s not an advertised or documented thing yet - it’s just early and you’re on the bleeding edge while it’s still being worked on. There’s nothing to enable on your account as far as I know.
@Hard@Work
I would note that there are some things that
node_compat supports that nodejs_compat does not support(at least afaik), so some packages may just not work on Pagesthat's my original point to all of this - the confusion behind that. but it seems mostly that's not a problem when building with
--platform=node
and it sounds like node_compat is on the way out (deprecated) for Workers? so overall the plan is to ship a worse experience?nodejs_compat_v2 will not be a worse experience - it's just earlyEhhhhh, not quite? While yes,
node_compat does support a lot of things out of the box, it is just using a 3rd-party polyfill library(which you may actually be able to use yourself when building, even on Pages). Thus, it adds a bit of bloat to your Functions compared to nodejs_compat/v2, which are natively implemented in the runtime, and thus add nothing to your FunctionsNot entirely accurate.
nodejs_compat_v2 isn't just runtime handled (though the runtime does do a little more lifting) - it does some unenv stuff at build-time too: https://github.com/cloudflare/workers-sdk/pull/5878TIL, thanks for the correction James!
is there any way to test if this will actually solve the problem? didn't realize I'm using something so bleeding edge it won't even build
you're likely going to need to create a minimal reproduction and file an issue unfortunately
I did
GitHub
🐛 BUG:
experimental:nodejs_compat_v2Not Working Local or Deployme...Which Cloudflare product(s) does this pertain to? Pages What version(s) of the tool(s) are you using? 3.61.0 [Wrangler] What version of Node are you using? 18.18 What operating system and version a...
so how is anyone else at CF using this experimental feature? that's what I'm confused about now
I'm sure someone on the team will get back to you when they're next available then. Sorry for the issues, hopefully they can get you a fix soon! For now, when I hit issues like this or features that Workers supports and Pages doesn't, I often just deploy the UI/frontend to Pages and then a Worker for my API/functionality.
what makes you think they are? There's disclaimers not to use it for production use, and it literally only landed a matter of weeks ago (v2)
yes I'm trying to avoid splitting them, because the end goal is to use NuxtHub which is all built on Pages
nodejs_compat compat flag (not v2) has been live for a long time, but it's not the same as node_compat. I use nodejs_compat and import from node:crypto (etc.) in lots of my workers today in production just fine though for exampleyes but the other problem is not even using nodejs_compat_v2
14:11:38.844 Error: Failed to publish your Function. Got error: Uncaught Error: Dynamic require of "events" is not supportednodejs_compat_v2 will be great and solve lots of compat issues with globals missing, importing from non-node: prefixed modules, etc. but it's just early and not fully done/impemented everywhere yetethis doesn't seem related to node: prfix
Without looking at your code and the build output line by line, I would guess something in your code or a module you load is importing
events. With node_compat, that's being stubbed out and the import/require removed. Without it, it's remaining, and then erroring at runtime.
This is just an artifact of what happens when you build code with something like esbuild (what wrangler uses), and all of the additional stubbed in polyfills
sometimes the errors you get out aren't going to be that usefulyes it's coming from a package - the point is that it's only an issue with
nodejs_compat and not node_compat=true
so if you say this will be resolved with _v2, I'll just wait I guess and keep my fingers crossedyes, that's by design.
nodejs_compat is not a replacement for node_compat and is limited. Thus why nodejs_compat_v2 was born, essentially, and it's just super early
(this is all very confusing I know, I'm sorry. It's a DX pain I've moaned about for what feels like years at this point. I'm also very hopeful _v2 is going to solve all of this so we can put node_compat behind us and in the past for good)I'd suggest you guys change the messaging from "
nodejs_compat and node_compat=true are different on purpose", to "nodejs_compat_v2 is going to replace both and function better"
because it just seemed like this was the designed experience on purposeI do imagine the documentation and messaging around Node.js compatibility will be updated once
_v2 is ready for production use, and the older methods can be deprecated/removed
because yes, agreed, the documentation around all of this sucksappreciate all your input, hopefully my issue has enough info for someone to fix this. we are trying to get compatibility for D1 database with Knex query builder (1.7M weekly downloads)
so kinda important for people who want to use D1 without Drizzle or Prisma
Agreed. We have a spreadsheet we maintain in the community for workers/pages compatibility which might be helpful if/when you hit more edge-cases in future: https://docs.google.com/spreadsheets/d/1T7j7FZZO7zmkrEegzhMeMtlFPIh-efYGMc7BuenMPWY/edit?usp=sharing
I also did a bit of a writeup about this poor DX a while back: https://github.com/cloudflare/workerd/discussions/1857
(that was before
_v2 existed, so doesn't mention that)