# prettyjson

Package for formatting JSON data in a coloured YAML-style, perfect for CLI output

## How to install

Just install it via NPM:

    $ npm install prettyjson

## Using it (from the CLI)

This package installs a command line interface to render JSON data in a more convenient way. You can use the CLI in three different ways:

Decode a JSON file: If you want to see the contents of a JSON file, just pass it as the first argument to the CLI:

    $ prettyjson package.json

Decode the stdin: You can also pipe the result of a command (for example an HTTP request) to the CLI to see the JSON result in a clearer way:

    $ curl https://api.github.com/users/rafeca | prettyjson

Decode random strings: if you call the CLI with no arguments, you'll get a prompt where you can past JSON strings and they'll be automatically displayed in a clearer way:

If you install the package globally (with `npm install -g prettyjson`), the CLI will be installed automatically in your PATH thanks to npm.

### Customizing colors via command line

Now it's possible to customize the colors of the output via environment variables, thanks to @bahamas10:

    $ PRETTYJSON_KEYS=red PRETTYJSON_DASH=blue PRETTYJSON_STRING=yellow prettyjson package.json

The available options are `PRETTYJSON_KEYS`, `PRETTYJSON_DASH`, `PRETTYJSON_STRING` and `PRETTYJSON_INDENT`.

## Using it (from Node.js)

It's pretty easy to use it... you just have to include it in your script and call the `render()` method:

    var prettyjson = require('prettyjson');

    var data = {
      username: 'rafeca',
      url: 'https://github.com/rafeca',
      twitter_account: 'https://twitter.com/rafeca',
      projects: ['prettyprint', 'connfu']
    };

    console.log(prettyjson.render(data));

And will output:

You can also configure the colors of the hash keys and array dashes (using colors.js colors syntax):

    var prettyjson = require('prettyjson');

    var data = {
      username: 'rafeca',
      url: 'https://github.com/rafeca',
      twitter_account: 'https://twitter.com/rafeca',
      projects: ['prettyprint', 'connfu']
    };

    console.log(prettyjson.render(data, {
      keysColor: 'rainbow',
      dashColor: 'magenta',
      stringColor: 'white'
    }));

Will output something like:

## Annotated source

You can check the annotated source for more information about how it works

## Running Tests

To run the test suite first invoke the following command within the repo, installing the development dependencies:

    $ npm install --dev

then run the tests:

    $ npm test

You can check the package's test coverage if you are one of those test paranoics

## Change Log

### 0.8.0 — February 23, 2013

- Fix: ENV vars were not being used correctly
- Add an option to change the color of the strings
- Minor codestyle improvements

### 0.7.1 — October 29, 2012

- Fix bug in 0.7.0 when input is an array

### 0.7.0 — October 25, 2012

- Allow having non-JSON characters at the beginning of the input string (ideal for curl -i)
- Add a renderString() method to be used by the CLI
- Change test reporter style to spec
- Upgrade dependencies to the last versions

### 0.6.0 — June 29, 2012

- Update dependencies to support Node.js v0.8
- Adding ability to use environmental variables

### 0.5.0 — June 24, 2012

- Updated dependencies, added support for Node.js up to 0.7.12
- Minor improvements in README file
- Add JSHint to the build process
- Add jake task to execute tests automatically
- Add test coverage info

### 0.4.0 — February 24, 2012

- Now prettyjson uses Mocha test framework instead of jasmine-node
- Fixed leak in a "key" variable

### 0.3.1 — February 15, 2012

- Modified website design
- Modify webpage link in package.json

### 0.3.0 — January 24, 2012

- Added CLI interface
- Now prettyjson package requires Nodejs 0.6.x

### 0.2.1 — January 23, 2012

- Fix: Bug when the JSON has attributes with booleans, integers or null values

### 0.2.0 — January 22, 2012

- Now using node-releasetools for the release process
- Disabled Node.js 0.6 from Travis CI temporally
- Minor copy in Readme.md

### 0.1.4 — December 1, 2011

- Added contributors to the Readme file

### 0.1.3 — November 17, 2011

- Fixed the GitHub publishing of tags in the jake task
- Updated package.json to make it compatible with Node.js 0.6.x
- Updated travis YAML file to use the new Node.js support on Travis

### 0.1.2 — November 14, 2011

- Updated Jakefile with tasks to automate publishing new versions

### 0.1.1 — October 11, 2011

- Added changelog jake task to add changelog automatically
- The library version is retrieved from `package.json` file

### 0.1.0 — October 10, 2011

- Initial release

## Contributors

- Dave Eddy dave@daveeddy.com
- Rafael de Oleza rafeca@gmail.com
- jiyinyiyong jiyinyiyong@gmail.com

## How to contribute

Good pull requests - patches, improvements, new features - are a fantastic help.

If you've spotted any small, obvious errors and want to help out by patching it, that will be much appreciated.

If your contribution involves a significant amount of work or substantial changes to any part of the project, please open a "contribution enquiry" issue first to check that the work is wanted or matches the goals of the project.

All pull requests should remain focused in scope and avoid containing unrelated commits.

Please follow this process; it's the best way to get your work included in the project:

1. Fork the project.

2. Clone your fork (`git clone git@github.com:<your-username>/<repo-name>.git`).

3. Add an `upstream` remote (`git remote add upstream git://github.com/<upsteam-owner>/<repo-name>.git`).

4. Get the latest changes from upstream (e.g. `git pull upstream <dev-branch>`).

5. Create a new topic branch to contain your feature, change, or fix (`git checkout -b <topic-branch-name>`).

6. Create the needed tests to ensure that your contribution is not broken in the future. If you are creating a small fix or patch to an existing feature, just a simple test will do, if it is a brand new feature, make sure to create a new test suite.

7. Make sure that your changes adhere to the current coding conventions used throughout the project - indentation, accurate comments, etc.

8. Commit your changes in logical chunks; use git's interactive rebase feature to tidy up your commits before making them public. Please adhere to these git commit message guidelines or your pull request is unlikely be merged into the main project.

9. Locally merge (or rebase) the upstream branch into your topic branch.

10. Push your topic branch up to your fork (`git push origin <topic-branch-name>`).

11. Open a Pull Request with a clear title and description.

If you have any other questions about contributing, please feel free to contact me.

## License

(The MIT License)

Copyright (c) 2011 Rafael de Oleza rafeca@gmail.com

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.