Installations
npm install bole
Developer Guide
Typescript
No
Module System
CommonJS
Node Version
20.18.0
NPM Version
10.9.0
Score
99.6
Supply Chain
99.5
Quality
80.6
Maintenance
100
Vulnerability
100
License
Releases
Contributors
Languages
JavaScript (100%)
Developer
rvagg
Download Statistics
Total Downloads
38,153,121
Last Day
152,771
Last Week
682,315
Last Month
2,616,246
Last Year
22,201,416
GitHub Statistics
271 Stars
89 Commits
15 Forks
7 Watching
1 Branches
8 Contributors
Bundle Size
5.85 kB
Minified
2.27 kB
Minified + Gzipped
Package Meta Information
Latest Version
5.0.17
Package Id
bole@5.0.17
Unpacked Size
40.72 kB
Size
11.50 kB
File Count
10
NPM Version
10.9.0
Node Version
20.18.0
Publised On
25 Oct 2024
Total Downloads
Cumulative downloads
Total Downloads
38,153,121
Last day
21.7%
152,771
Compared to previous day
Last week
-1.2%
682,315
Compared to previous week
Last month
31.9%
2,616,246
Compared to previous month
Last year
171%
22,201,416
Compared to previous year
Daily Downloads
Weekly Downloads
Monthly Downloads
Yearly Downloads
Dependencies
2
Dev Dependencies
5
bole
A tiny JSON logger, optimised for speed and simplicity
Log JSON from within Node.js applications. The log format is obviously inspired by the excellent Bunyan and is likely to be output-compatible in most cases. The difference is that bole aims for even more simplicity, supporting only the common-case basics.
bole is designed for global singleton use. Your application has many log sources, but they all aggregate to the same sources. You configure output in one place for an application, regardless of how many modules and dependencies are also using bole for logging.
Example
mymodule.js
1const log = require('bole')('mymodule') 2 3module.exports.derp = () => { 4 log.debug('W00t!') 5 log.info('Starting mymodule#derp()') 6}
main.js
1const bole = require('bole') 2const mod = require('./mymodule') 3 4bole.output({ 5 level: 'info', 6 stream: process.stdout 7}) 8 9mod.derp()
1$ node main 2{"time":"2014-05-18T23:47:06.545Z","hostname":"tweedy","pid":27374,"level":"info","name":"mymodule","message":"Starting mymodule#derp()"}
Features
- Very fast, bole has been optimised for common cases and is designed to add minimal overhead to your applications, use the
bole.setFastTime()
feature (below) to make it even faster - Arbitrary log names, create a logger by calling
const log = bole('logname')
and'logname'
will be attached to the output - Loggers have 4 levels / methods:
log.debug()
,log.info()
,log.warn()
,log.error()
- Log methods accept
console.log()
style strfmt output ( usingutil.format()
):log.warn('foo %s', 'bar')
- Log methods accept arbitrary objects that extend the log output data, each property on the object is attached to the debug output object
- Log methods accept
Error
objects and print appropriateError
properties, including a full stack trace (including any cause where supported) - Log methods accept
http.IncomingMessage
for simple logging of an HTTP server'sreq
object. URL, method, headers, remote host details will be included in the log output. - Newline separated JSON output to arbitrary streams
- Any number of output streams, each with configurable minimum log-levels
- Fast short-circuit where no loggers are configured for the log-level, effectively making log statements a noop where they don't output
- Sub-logger to split a logger for grouping types of events, such as individual HTTP request
- Object-logging (i.e. not automatically stringified) if you pass an
objectMode:true
stream for output.
API
bole(name)
Create a new logger with the supplied name
to be attached to each output. If you keep a logger-per module you don't need to pass loggers around, keep your concerns separated.
logger#debug(), logger#info(), logger#warn(), logger#error()
Loggers have 4 roughly identical log methods, one for each of the supports log-levels. Log levels are recorded on the output and can be used to determine the level of detail passed to the output.
Log methods support the following types of input:
-
Error
objects: log output will include the errorname
,message
, completestack
and also acode
where there is one. Additionally you can supply further arguments which are passed toutil.format()
and attached as a"message"
property to the output:log.warn(err, 'error occurred while fetching session for user %s', user.name)
-
http.IncomingMessage
for simple access-log style logging. URL, method, headers, remote address and remote port are logged:log.info(req)
, further data can be provided for a"message"
property if required. -
Arbitrary objects whose properties will be placed directly on the logged output object. Be careful passing objects with large numbers of properties, in most cases you are best to construct your own objects:
log.debug({ dbHost: 'foo', dbPort: 8080 }, 'connecting to database')
, further data can be provided for a"message"
property if required. -
console.log style output so you can treat loggers just like
console.log()
:log.info('logging a string')
,log.info('it has been said that %d is the meaning of %s', 42, 'life')
,log.debug('foo', 'bar', 'baz')
.
If you require more sophisticated serialisation of your objects, then write a utility function to convert those objects to loggable objects.
logger()
The logger
object returned by bole(name)
is also a function that accepts a name
argument. It returns a new logger whose name is the parent logger with the new name appended after a ':'
character. This is useful for splitting a logger up for grouping events. Consider the HTTP server case where you may want to group all events from a particular request together:
1const log = bole('server') 2 3http.createServer((req, res) => { 4 req.log = log(uuid.v4()) // make a new sub-logger 5 req.log.info(req) 6 7 //... 8 9 // log an error against this sub-logger 10 req.log.error(err) 11})
In this case, your events would be listed as something like "name":"server:93f57a1a-ae59-46da-a625-8d084a77028a"
and each event for a particular request would have the same "name"
property, distinct from the rest.
Sub-loggers can even be split in to sub-sub loggers, the rabbit hole is ~bottomless.
bole.output()
Add outputs for application-wide logging, accepts either an object for defining a single output or an array of objects defining multiple outputs. Each output requires only a 'level'
and a 'stream'
, where the level defines the minimum debug level to print to this stream and the stream is any WritableStream
that accepts a .write()
method.
If you pass in a stream with objectMode
set to true
then you will receive the raw log objects rather than their stringified versions.
1bole.output([ 2 { level: 'debug', stream: fs.createWriteStream('app.log') }, 3 { level: 'info', stream: process.stdout } 4])
bole.reset()
Clears all output streams from the application
bole.setFastTime()
If speed is something you care about and you can handle time in milliseconds since epoch (Date.now()
) rather than the full ISO string (new Date().toISOString()
) in your logs then use bole.setFastTime(true)
to shave off some precious microseconds.
Note that this will reset to the default of false
when you use bole.reset()
Additional features
If you need to serialise specific types of objects then write a utility function to convert to a loggable object.
If you need a special kind of output then write a stream to accept output data.
If you need to filter a present output data in a special way, write a package to do it and publish it in npm.
License
bole is Copyright (c) 2014 Rod Vagg @rvagg and licensed under the MIT License. All rights not explicitly granted in the MIT License are reserved. See the included LICENSE.md file for more details.
No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
no binaries found in the repo
Reason
0 existing vulnerabilities detected
Reason
license file detected
Details
- Info: project has a license file: LICENSE.md:0
- Info: FSF or OSI recognized license: MIT License: LICENSE.md:0
Reason
packaging workflow detected
Details
- Info: Project packages its releases by way of GitHub Actions.: .github/workflows/test-and-release.yml:24
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
- Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/test-and-release.yml:31: update your workflow using https://app.stepsecurity.io/secureworkflow/rvagg/bole/test-and-release.yml/master?enable=pin
- Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/test-and-release.yml:35: update your workflow using https://app.stepsecurity.io/secureworkflow/rvagg/bole/test-and-release.yml/master?enable=pin
- Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/test-and-release.yml:13: update your workflow using https://app.stepsecurity.io/secureworkflow/rvagg/bole/test-and-release.yml/master?enable=pin
- Warn: GitHub-owned GitHubAction not pinned by hash: .github/workflows/test-and-release.yml:15: update your workflow using https://app.stepsecurity.io/secureworkflow/rvagg/bole/test-and-release.yml/master?enable=pin
- Warn: npmCommand not pinned by hash: .github/workflows/test-and-release.yml:20
- Warn: npmCommand not pinned by hash: .github/workflows/test-and-release.yml:40
- Warn: npmCommand not pinned by hash: .github/workflows/test-and-release.yml:46
- Info: 0 out of 4 GitHub-owned GitHubAction dependencies pinned
- Info: 0 out of 3 npmCommand dependencies pinned
Reason
Found 0/11 approved changesets -- score normalized to 0
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
detected GitHub workflow tokens with excessive permissions
Details
- Warn: no topLevel permission defined: .github/workflows/test-and-release.yml:1
- Info: no jobLevel write permissions found
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
- Warn: no security policy file detected
- Warn: no security file to analyze
- Warn: no security file to analyze
- Warn: no security file to analyze
Reason
project is not fuzzed
Details
- Warn: no fuzzer integrations found
Reason
branch protection not enabled on development/release branches
Details
- Warn: branch protection not enabled for branch 'master'
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
- Warn: 0 commits out of 19 are checked with a SAST tool
Score
3.8
/10
Last Scanned on 2025-01-20
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More