I have recently ventured into the OS community for the first time. Here are some of the general and tech-related lessons I picked up along the way. General lessons If you are wondering where to start getting involved with a project, pick something that nobody else wants to do. Do this until you feel ready for the next step or until somebody asks you to do something else.I started with upping code coverage and single handedly got Mocha’s coverage from 78% to 88%. Something I was not very excited about initially but very proud in retrospect. Observe the PR list to gain an understand of the process. It can give you information about who the maintainers are or any areas requiring immediate attention. Do not fear a response from the maintainers. Most of the time people are helpful and grateful for the effort.I received some really nice messages of gratitude which only spurned on my desire to do more. Obviously always run linting and tests locally before committing, it goes without saying but without a hook to run it it’s easily forgotten. Once u have a PR people tend to be quick to respond or apologetic if there is a long delay. You can expect:1. to sign a Contributor License Agreement.2. tests which pass locally to run on multiple CI boxes, potentially SAAS you have not used before.3. tests to run on multiple versions of Node, some which may fail if you have not tested it locally on that version. Tech-related lessons: Colours in the terminal:- terminals use ANSI escape codes. Not all SAAS CI boxes support them so need a mechanism to return a string value of code.- terminal also requires a TTY in order to print coloured output. Again not all SAAS CI boxes support TTY so some libraries checks if both stdio streams are associated with a TTY. In Node looks like `tty.isatty(1) && tty.isatty(2)`. Testing console.log:- console.log() in Node uses process.stdout.write()- its a writable stream associated with ‘stdout’- override a console.log with:- (be sure to cache its value initially and reset after)- WARNING: altering a global is not something I recommend, but its not always possible to control a libraries code and it can be worth the hit in order to gain some vital unit tests. process.stdout.write = function (string) {myArray.push(string); // 'hello'};console.log('hello'); Keeping your fork up to date:- useful if you aim for multiple PR’s #git remote add upstream <main repo>#git fetch upstream#git merge upstream/master#git push origin master I hope you found this article useful on some way, I certainly learnt a lot going through the OS lifecycle myself. Originally published on http://www.developerknowhow.com/2400/what-i-learnt-from-my-venture-into-open-source
