1 minute read

I recently updated my Next.js Template to Next.js 13 and have been wrestling with some consequences around middleware interactions with NextAuth.js.

While troubleshooting this, I added a logging package to my Next.js middleware that uses the lodash isPlainObject function. Since that package is articulated using my NPM Package Template, it simply imported the whole Lodash library, since the template has babel-plugin-lodash in place to cherry-pick any referenced functions.

My Next.js Template dev environment demo is hosted at Vercel, which unaccountably does NOT display the logs for my middleware. 🙄 Fortunately I’m using the same template on another project hosted at AWS Amplify, which has better logging (although slower builds), so I added the same logging function to that project, and…

My build failed!

AWS Amplify build failure (click to zoom)

Most surprising is that the stack trace fingers lodash as the culprit. Hard to imagine a more deeply-vetted package, and my usage of it is about as vanilla as it comes.

Once I did a little digging, I found people yelling about this all over the place. Turns out the Next.js 13 Edge Runtime constraints are playing havoc with some popular packages.

This comment was particularly interesting, because the author found the culprit in lodash!

This one line in the lodash package executes dynamic JavaScript for absolutely no good reason that I can see:

/** Used as a reference to the global object. */
const root =
  freeGlobalThis || freeGlobal || freeSelf || Function('return this')();

That’s… disappointing. Until lodash patches this, a lot of people are going to have to do a lot of workarounds. Including me!

Fortunately, I found a pretty easy one. Most lodash functions are also published as individual packages. I was able to drop the stand-alone lodash.isplainobject dependency into my logger package and my build proceeded without error.

That works for my logging application, but in the more general case I’d be giving up function chaining and other goodies built into the full lodash package.

Meanwhile, I’m subscribed to this GitHub issue and am tracking it closely!


The edge-network logging problem turned out to be enough of a pain in the ass that I published my new edge-logger package to solve it across all my projects.

Give it a shot and let me know what you think!