Introducing a new ndjson logger with 🚀

Emojis are everywhere. They can be used to 📣 in a compact form or simply add some 👻 to your message. For JavaScript Studio, I started using emoji in log messages to highlight ⚠️ and 🚨, and I found that it actually adds readability. However, putting plain emoji directly into log files is not what I wanted. My preferred log file format is ndjson and I would like to have emoji as an optional UI bling ✨.

So I made a tiny ndjson logger, and a CLI to format the logs ✅. I released it as open source software under the MIT license, and this is what it looks like:

You can install it with npm install @studio/log -S. Read all about the API on the GitHub page.

javascript-studio/studio-log

Disabled by default

There is no default output stream configured to prevent unwanted log output in test cases or when reusing libraries for a command line tool. Set stdout as the log destination like this:

require('@studio/log').out(process.stdout);

A different approach to log levels

There is another fundamental difference to other log libraries: There are no log levels. Yes, no “info” or “debug” anymore. And while “warn” and “error” are a thing in @studio.log, there is no severity level associated with any of the logger functions. So why did I do that?

Whenever I used log files to trace an issue, the most important logs where the debug entries. They tend to have the relevant details about HTTP requests or configs in use. The screaming error is just where the problem surfaces, but the stack trace does not help with reproducing an issue. Therefore I never filter logs based on log levels in production environments of a server application. However, when you have a command line tool, you might want some control over what is logged and what is not. In this case, I want to mute certain types of logs, and this is what @studio/log allows me to do. I can mute logs by namespace, by topic or only a specific combination of namespace and topic.

What are namespaces and topics?

While namespaces work like the “classic” log instance names, topics are the functions that the logger instances expose. They make the log statements a bit more expressive and the topics are mapped to emojis in the emojilog CLI to ✅ ⚠️ 🐛 🚨 🙈 🔺 🔻 📤 📥 📡 🏁 🚀 ⛔️ ✨ 📣 💾 ⏱ 💰 🔢 and 👻.

const logger = require('@studio/log');
const log = logger('app'); // "app" is the namespace
log.launch('my service', { port: 433 }); // "launch" is the topic

Why not Bunjan, Bole or Pino?

I like Bunjan, Bole and Pino. They’re all great when you need a logger for a Node server application. They add the hostname and process ID by default and, in case of Bunjan, have nice built-in features for log file rotation and more. The environments I’m targeting are AWS Lambda functions and command line tools where these features have no value. Especially for Lambda functions, the size of the deployed source is important for fast cold starts. I use browserify to merge all sources into a single file and @studio/log has a minimal footprint when used like this.

If you like the project and need an advanced feature, it can be added with a custom transform stream. See the project readme for details.

🏁 Thanks for reading and happy logging.