I am experiencing an issue with today’s deployment that has never before occurred. When I try to access any resource/page on the site I get this same error, even for static pages:
Runtime.UnhandledPromiseRejection - Error: Dynamic require of "util" is not supported
Runtime.UnhandledPromiseRejection: Error: Dynamic require of "util" is not supported
at process.<anonymous> (file:///var/runtime/index.mjs:1131:17)
at process.emit (node:events:527:28)
at emit (node:internal/process/promises:140:20)
at processPromiseRejections (node:internal/process/promises:274:27)
at processTicksAndRejections (node:internal/process/task_queues:97:32)
Netlify internal ID: 01GEMEX3WE7AWDTN9PP79PHYZV
The following is the only issue that I can find in common, and it does seem to have the same behavior:
I have undeployed this in favor of Friday’s release.
This is fixed, which required a full day. It was as simple as clearing the Netlify cache before deploying. Actually it was not simple because it wasn’t apparent that the operation exists or even to try it. It seems that clearing the cache removes the node_modules directory, which can be important even with what seems to be basic updates to dependencies.
Sure. We also discussed with business plan support after this. I’m pasting part of that communication because the error was not caused by the two updated direct dependencies but one or more transient dependencies up/down (per your visual context) the tree.
We updated two dependencies to current versions:
After many build and deploy tests it was proved that these two updates were fine in themselves, but apparently some deep transitive dependenc[y][ies] of daisyui, or possibly even any of our direct library dependencies, seemed to change implementation without updating their version. Our final conclusion was to rule out daisyui transitive dependencies due to the very latest tests indicated the problem was in another unidentified depenencies branch.
In the end, our lead slacked this message:
In fact why exactly clearing cache has helped is a mystery to me, because, as I understand, theoretically, package-lock should contain all of the information that would identify the exact state of the node_modules directory (provided that everything works correctly), but something still has gone wrong…