Pretty-logs NPM

Pretty Logs

Welcome to pretty-logs. pretty-logs is a JavaScript logging tool.

WARNING:

This library is still under active development and the API is likely to change. This was evidenced in the jumpt form 0.4.2 to 0.5.0.

Quickstart

npm install pretty-logs

Usage

import plog from 'pretty-logs';

plog({ level: 'debug', message: 'Login debug', extra: { category: 'AUTH' }});

plog({ level: 'info' , message: 'Login info', extra: { category: 'AUTH' }});

plog({ level: 'warn' , message: 'Login warn', extra: { category: 'AUTH' }});

plog({ level: 'error' , message: 'Login error', extra: { category: 'AUTH' }});

Here is how the above looks in the console

pretty logs

You can play with this library at pretty-logs sandbox.

NOTE:

The above will work very well on Safari and Chrome, however, Firefox and IE/Edge are inconsistent. As a result, we have added a safe mode for these inconsistent browsers. The safe mode will render like this:

FireFox (54)

pretty logs firefox

FireFox Developer Edition

pretty logs firefox developer edition

Motivation

This library was created because I became tired of moving my custom rolled logging library from project-to-project. I wanted this to be an easy way to use this minimal library in my future projects and pick up on the improvements I make as i go. I also wanted to work with open source projects and attempt to maintain my own.

Contributing

I am always happy to have people contribute to this project. Please start by reading this projects code of conduct.

Getting Started

1. clone repo

git clone git@github.com:tkjone/pretty-logs.git

2. move into pretty-log directory

cd ./path/to/pretty-logs

3. install dev dependencies

npm install

4. sanity-check - run tests

npm test

Please note that the tests are super baren right now. Step 4 is meant to illustrate a working project.

From here, you can checkout pretty-logs in an example app to see what it looks like by moving into examples/example-app and than run npm install and npm start. If you open the console you will see your nicely formatted logs.

The above works because we npm link pretty-logs. See package.json.

Scripts

If you intend on running the generate-changelog command you will need to install github-changes globally first:

npm install github-changes -g

After you have cloned this repo and installed the npm dependencies, it is a good practice to run npm run validate. This script is going to run prettier and the tests.

Git Workflow

We use Github Flow and Interactive Rebasing for this project. Here is a simple overview of this workflow:

1. Checkout a new feature/bug-fix branch based off master

git checkout -b <branchname>

2. Add commits

git add
git commit

3. Get latest from master

git fetch origin

4. Sync with master through interactive rebasing - Here's Why

git rebase origin/master

4. If you don't have conflicts, skip this step. Otherwise, resolving them.

git rebase <resolving-command-specific-to-your-case>

5. Cleanup your branch through rebasing - see here

git rebase -i HEAD~<how-far-back-you-want-to-go>

6. Push your branch

git push origin <branchname>

7. Make a PR

8. Have your PR code reviewed

8. Once your PR is approved, update the CHANGELOG and wait for it to be merged into master

Git Commit Messages

All commit messages must have a Subject and Body. Here is an example of the structure of our commit messages:

Example

issue <issue-number> <subject>
# blank line
<body>

For example:

issue #6 Formatting Safari

Resolves repeating images in the safari console

Also write your git commit messages using an imperative tone. For example:

Add new linting tool

Limit the number of characters in string function

Git Rules

These apply to git commit messages and pull requests

All Feature work should be done on a feature branch
The subject of the git commit message and pull request, should NOT exceed 50 characters
The first word of the Subject, after the issue number, should be capitalized
The body of the git commit message should wrap the line at 80 characters
Always add the Fixes issue-number to the bottom of your pull requests body - example here
Git branch naming convention: issue-6-descriptive-subject
Pull request body text should have details summarizing the problem and why the change was made
Use a Pull Request whenever you want input from other developers. Its not just for a completed piece of work
Be sure to avoid rebasing over your own commits when you have created a pull request. The problem with this is that if someone left a comment on one of the files you rebased, those comments will be lost.
When merging a Pull Request, we use squash and merge

Git Hooks

We have a pre-commit git hook, which runs when you run git commit locally. This hool runs prettier. Big thanks to husky which help make this process very easy.

console.js console.style log log.js winston log4js

Notes

This section just contains some knowledge that I acquired while developing/maintaining this library from an npm package perspective. For example, running npm version patch will auto-incrememnt your package.json's version property. Similiarly, you can swap patch for minor or major. Very nice.

If you notice the version in our package.json is "version": "0.0.0-semantically-released" this is because we are handling this process with semantinc-release-cli