Next.js

Next.js: The Server Function Logging Dance

Today's episode covers a fascinating back-and-forth in the Next.js codebase around Server Function logging defaults, plus some solid documentation improvements and build system refinements. We saw three related PRs that tell the story of finding the right balance between useful developer tools and clean console output, along with helpful community contributions fixing docs and improving the developer experience.

Duration: PT4M8S

https://podlog.io/listen/next-js-36fde2ae/episode/next-js-the-server-function-logging-dance-27edbe99

Transcript

Hey there, developers! Welcome back to another episode of the Next.js podcast. I'm your host, and wow, do we have an interesting story to tell today from the Next.js codebase. You know those moments when a team is really thoughtfully considering the developer experience? Well, we just witnessed one play out in real time.

Let me paint you the picture. We had ten pull requests merge yesterday, and the most fascinating part is this trilogy of changes around Server Function logging that really shows how the Next.js team thinks about defaults and developer experience.

It all started with PR 89321 from unstubbable, who made Server Function logging opt-in via a new `logging.serverFunctions` config option. The reasoning was solid - they wanted to reduce noise in development logs by default, just like how fetch logging works. Makes sense, right? Less clutter in your terminal, cleaner development experience.

But here's where it gets interesting. Just a few hours later, the same contributor submitted PR 89407 that completely reversed course! They restored Server Function logging to be enabled by default. And you know what? This wasn't a mistake or flip-flopping - it was thoughtful iteration. The team realized that the original opt-in approach in the earlier implementation was actually an intentional design decision, and making it opt-in was being overly conservative.

Now developers get the helpful logging by default, but they can still turn it off if they want a quieter console. It's that sweet spot between helpful and not overwhelming.

Then came PR 89408, which added one more refinement - skipping the logging for 'use cache' functions because the output wasn't quite ready for prime time yet. It was showing internal details that weren't useful for developers.

I love this progression because it shows real product thinking in action. Start with one approach, listen to feedback, consider the broader impact, then iterate quickly. That's how you build great developer tools.

Beyond our logging saga, we got some really nice community contributions. Jan Amann fixed some broken code snippets in the custom server docs - you know how frustrating it is when you copy-paste example code and it doesn't work right away. Those little fixes make such a difference.

Pavan Shinde contributed a delightfully consistent change, replacing "can not" with "cannot" across the documentation. It might seem small, but consistent language makes the docs feel more polished and professional.

Joseph improved the package bundling documentation by adding multi-package manager syntax, showing the correct way to run commands with npm, yarn, and pnpm. These kinds of contributions really help developers who might be coming from different tooling backgrounds.

We also saw some important infrastructure work from JJ Kasper, re-adding build-complete traces for webpack. This was a partial revert of an earlier change, recognizing that the additional tracing was still necessary. Sometimes you have to take a step back to move forward correctly.

And there was a solid fix for server actions transforms in route handlers, making sure that `node_modules` get processed correctly. These kinds of edge case fixes keep the ecosystem running smoothly.

For today's focus, if you're working with Server Functions in your Next.js app, take a moment to appreciate that you now have really thoughtful logging defaults. The logs will be there when you need them, showing you what's happening with your server functions during development, but you can always opt out if you prefer a quieter experience.

Also, if you're using custom servers or the experimental bundle analyzer, double-check your setup against the updated docs - there were some helpful corrections that might save you some debugging time.

That's a wrap on today's episode! Ten pull requests, one great story about thoughtful iteration, and a bunch of polish that makes Next.js just a little bit better every day. Keep building amazing things, and we'll catch you tomorrow with more updates from the Next.js world!