npm bash-conf, for sharing configs between bash and node

API keys, DB authentication, passwords, system paths and other things of that nature dont belong in a Git repo.

They belong in a lovely config file created by an install script run after cloning a repo. That’s how I try and do things these days anyway.

I use a lot of bash scripting for big queries and file manipulation, often creating strings and files in Coldfusion and saving them to Amazon S3 or the HDD for a bash script to sort out later.

So these install scripts ask for db credentials, API keys etc and you type your responses in to match the environment you’re on (production, staging, dev) and the bash scripts work away after importing the data.

I’ve started using node js for these back end processes more and more frequently now, allowing me to develop more complex scripts that are easier to debug, easier to maintain and most of all means my team mates can work on them as well!

In order to avoid having to have another JS friendly config file for my node scripts to read and also to avoid passing data in when the scripts are called I’ve written an npm module that can read the same config file bash uses.

https://www.npmjs.com/package/bash-conf

To quickly summarise how it works, I’ll just dump the usage snippet from the README. You just have to give it the path to a config file which is just a list of simple FOO=BAR style declarations

var path = process.argv[ 2 ],
BashConf = require('bash-conf'),
bashConf = new BashConf();

bashConf
.read( path )
.then(function( data ) {
console.log( 'what is foo', data.FOO );
console.log( 'this should be empty -> [', data.EMPTY_VAR, ']' );
})
.catch( function( err ) {
console.log( err );
});

If you want more info, get in touch, use Github issues or RTFM!
Also get in touch if the manual needs updating…

ConsoleFancy – my first npm module

First off, I’m not really sure if it’s a module, or a package, or a repo or what. Maybe it’s all three. I’ll find out one day.

More importantly I’ve added to npm! You can install a package that I’ve written right now – it was ridiculously easy to do.

vi test.js

// create the following in test.js
// var ConsoleFancy = require('console-fancy'),
// consoleFancy = new ConsoleFancy();
// consoleFancy.header('hello');

npm install console-fancy
node test.js

After all that hard work you should see hello wrapped in the default top level borders – currently a lot of # symbols. You can switch it to consoleFancy.header('hello',2); for the second level header or when you init the object you can pass it more levels and specify the border, padding and edges. I’ll expand the docs to show how to do that when I get some more time.

It all came about as I was writing a Node.js app to download and process Apache log files from my Load Balancer, when I got frustrated at the amount of times I’d written console.log(). It was all blending into one output and was hard to read what was going on. I wanted to break the output up so I could clearly see major points in my output.

So I wrote a function that I could pass my log message to, as well as a level heading, like an <h1> or <h2>. This worked fine but I wanted to be able to re-use it and share it with my colleagues.

I created a new script and included that with require('./ConsoleFancy.js') and then thought “How do I get this into npm? Can I add this, and just install it like all the other packages?”

Well the answer is yes. It’s incredibly easy. It’s all explained here:
https://docs.npmjs.com/getting-started/publishing-npm-packages

In short: Once I’d signed up at npmjs.com, as I’d already created my node module/package thing, I just ran the following to get it published:

// this created the package.json for me - it asks you questions, you answer them
npm init

// log into the npm site, so it publishes to your account
npm login

// then you publish it... if there's any problems it errors and you can try again
npm publish

The process gets most of the information it needs from the package.json. When I ran the init command it asked me what the Github repo was, so I actually cancelled the process, created a repo, pushed it all live and then started again.

Adding the Git repo means it’s linked from the npmjs site, so other people can contribute, submit pull requests, issues etc.

When you update the module, once you’ve made you changes, commited your code, you run the following command:

// patch can be replaced with minor or major
// https://docs.npmjs.com/getting-started/semantic-versioning
npm version patch

This command is brilliant, it does 2 things:

  1. Updates the package.json file, incrementing the version number based on your patch/minor/major keyword
  2. Creates a Git tag for your repo so you can get back to this release commit – the tag matches the version number

Once you’ve created your new version you just run npm publish again and it not only pushes it npmjs.com, but also pushes the new commit and tag to Github!

It’s also worth making a README.md file file (or whatever format you like for your README) as this gets pulled into your npmjs page – without it you just get a blank page with the project name on it.

So if you find yourself writing utilities and tools for Node.js, and you’re considering sharing them then go ahead and do it. It’s so simple, it’ll make your life easier in your next project, you’ll be helping others and if it picks up you can get some help to improve it.

Just don’t forget to check if someone else has already written it… I did look, but I bet someone’s already written a ConsoleFancier.

Project links: