loglevel

loglevel is a minimal logging library for JavaScript that wraps the browser and Node.js console object with level-based filtering (trace, debug, info, warn, error, and silent) without introducing any new dependencies or console-clobbering wrapper calls. It ships as a single file weighing about 1.4KB minified and gzipped, works via CommonJS, AMD, or a global script tag, and gracefully degrades in older or console-less environments so logging calls never throw.

Because loglevel binds directly to native console methods rather than wrapping them, stack traces and line numbers stay intact in browser devtools. It supports named child loggers via getLogger(), persists a chosen log level to localStorage or cookies across page loads, and ships its own TypeScript definitions, making it a common lightweight default with no configuration overhead.

What You Get

• Level-based logging methods (trace/debug/info/warn/error) that fall back gracefully when a specific console method isn’t available
• A single dependency-free file, about 1.4KB minified and gzipped, with no build step required to use it
• Persisted log levels via localStorage (or a cookie fallback) so a developer’s chosen verbosity survives page reloads
• Named child loggers via log.getLogger(name) for scoping verbosity independently across modules
• Bundled TypeScript type definitions, so no extra @types package is needed

Common Use Cases

• Adding leveled logging to a browser app without pulling in a full logging framework
• Quieting noisy console output in production while keeping a log.setLevel(“trace”) escape hatch for live debugging
• Sharing one logging call site across Node.js and browser code via CommonJS/AMD/global support
• Giving each module or subsystem its own named logger so teams can turn up verbosity for just one area

Under The Hood

Architecture The entire library lives in a single UMD-wrapped file, lib/loglevel.js, that exposes one default Logger instance and a getLogger(name) factory for named child loggers tracked in an internal _loggersByName map. Each Logger computes its effective level from a three-tier precedence (an explicit userLevel, then a defaultLevel, then a level inherited from the root logger) and replaceLoggingMethods() re-binds the five level methods directly to native console methods (or a noop) whenever the level changes, trading a small amount of work on setLevel()/rebuild() for zero overhead on the hot logging path itself. A rebuild() call on the root logger cascades to every named child, giving the whole system a simple, closure-based single-responsibility design rather than a class hierarchy or event bus.

Tech Stack Runtime dependencies are intentionally empty (package.json declares “dependencies”: {}), and the library targets Node >= 0.6.0 with plain ES5-style closures and no transpilation required to consume it. The build and test tooling is Grunt-based (grunt-contrib-concat, grunt-contrib-uglify, grunt-contrib-jshint) with grunt-contrib-jasmine plus grunt-contrib-connect driving real-browser test runs, and a separate tsc/ts-node pass exercises the hand-written index.d.ts type definitions. Prebuilt dist/ bundles are checked in for direct <script> consumption or CDN use alongside the npm package.

Code Quality The test/ directory holds roughly a dozen Jasmine specs covering level setting, localStorage/cookie persistence, console-fallback behavior when specific methods are missing, and multiple/named loggers, plus a dedicated type-test.ts checked against the shipped type definitions. CI (.github/workflows/ci.yml) runs JSHint linting, a dist build, and a Node test matrix spanning several LTS versions on every push and pull request. Error handling is deliberately minimal and by design: normalizeLevel() throws a TypeError on an invalid level argument, while every actual logging call is built to never throw even when no console is present.

API Design The public surface is intentionally tiny: five logging methods, setLevel/getLevel/setDefaultLevel/resetLevel, enableAll/disableAll, and getLogger(name) for scoped child loggers, so a first log line requires nothing more than requiring the module and calling a method. Complexity is opt-in rather than upfront — persistence, named loggers, and a custom methodFactory for plugin authors are all available but never required for the common case. The README documents every method’s exact behavior and edge cases (e.g. IE trace() quirks) in one place, which keeps the learning curve close to zero for the default usage pattern.