Skip to content

Releases: alextremp/logda

v1.2.0

03 Jan 11:56
Compare
Choose a tag to compare
  • feat(level) change log level at runtime

    • Enable using the setLogdaLevel after the first log initialization.
    • setting the logda level changes all logs level
    • window.localStorage's logda.level still rules over the runtime setting level

v1.1.2

02 Jan 03:43
Compare
Choose a tag to compare
  • update versiona to v4
    • remove unnecessary regexp in travis yml
  • remove unnecessary dev dependencies for removed chart benchmarks demo

v1.1.1

02 Jan 01:06
87f044c
Compare
Choose a tag to compare
  • add social media logo and added it to readme

v1.1.0

31 Dec 03:30
470fd05
Compare
Choose a tag to compare

Tasks:

  • task(lgtm) add static code analyzer badge

  • add loggers benchmark (#4)

v1.0.1

30 Dec 03:55
Compare
Choose a tag to compare
  • fix(runkit)

fix the runkit file name key to make it available

v1.0.0

29 Dec 04:48
Compare
Choose a tag to compare

v1.0.0

  • Added documentation
  • MVP tested in other projects

Features

  • 🚀 Efficient logger: Will not run unnecessary operations, as all logger operations are delegated with an arrow function
  • Pretty printer: When enabled, distinguish different modules or files using tags
  • 💡 Developer ready: Set the logda.level into your window.localStorage to enable logda loggers for the apps you're reviewing (if you don't remove it from the local storage, you'll be able to review logs the next time you visit the page!)

Usage

Install

npm install logda --save

Create a root logger for your module: (optional but recommended for better log messages)

logger.js

import {logda} from 'logda'

const LOG = logda('my-app')

LOG.info(() => 'Logda log initialized')

export default LOG
  • The exported LOG is a logda logger already, you can call all level methods on it, but also allows creating sub-loggers by calling the logger method. In this case, the .info call (if info is enabled) will print:

    [INFO] my-app> Logda log initialized
    

Import this root logger to all files requiring a logger: (for example, MyService.js)

MyService.js

import LOG from './logger.js

const log = LOG.logger('MyService')

class MyService {
    // ...
    aMethod(params) {
      log.debug(() => ['aMethod', {params}])
    }
}

  • The created log is a LOG sub-logger that when debug is enabled will print a message like:
    [DEBUG] my-app|MyService> aMethod {...}
    

Write logs

Logda is intended to be used with arrow functions, so to log messages, call the level method with an arrow function:

log.debug(() => 'log messages as simple strings')
log.debug(() => ['log complex data inside an array', {
  aKey: 'aValue',
  another: calculatedData()
}])

Encapsulating data into an object {} will help you to review it correlating key-valued data in message logs

Change the log level

Logda accepts 'trace', 'debug', 'info', 'warn', 'error', 'off' levels.

Console correspondency:

  • log.trace => console.trace
  • log.debug => console.log
  • log.info => console.info
  • log.error => console.error

'off' is intended to disable all logs including 'error' logs.

  • Developer-only level:

In your browser's console, write:

window.localStorage.setItem('logda.level', 'debug')
  • Application level:

In case that you want a lower level to log messages (Node environments, loc/dev builds, ...), you can enable a specific logda level programmatically:

logger.js

import {logda, setLogdaLevel} from 'logda'

setLogdaLevel('info')

const LOG = logda('my-app')

LOG.info(() => 'Logda log initialized')

export default LOG

In this case, 'Logda log initialized' will be printed directly

In browser environments, the localStorage 'logda.level' (if set) will override the application level

Contributing

🔧 Maintenance info

Available Scripts

npm run...

  • phoenix to reset the project reinstalling its dependencies
  • lint to check the code format
  • test to run the project tests
  • check to run both lint&test
  • coverage to get an html test coverage report
  • build to build the project
  • versiona to publish a new version of the library (in Travis CI)

Create a PR

Use the PR template to explain the better possible:

  • Why the PR should be merged
  • How can be checked

Deploying

This project uses Travis CI for:

  • PR validation
  • Merge to master validation
  • NPM publications on Release tag creation

To create a new Release, take in mind:

  • The Release Tag must be named vX.Y.Z where X.Y.Z are the semver numbers that will correspond to the published package's version.
  • Travis CI will launch the versiona.js script which will:
    • Update the package.json to the X.Y.Z version set in the Release Tag
    • Publish the NPM package with the X.Y.Z version

v0.0.1

16 Dec 00:44
Compare
Choose a tag to compare

MVP version

  • includes minimal logger
  • error handling
  • use of localStorage to override logger level