Discussions about modularity are recurrent. Some people say that each function should be a separate module/file/package; others say that methods should be contained by a package and grouped by similarity/concerns; and there is still a 3rd group that thinks that a single namespace is the way to go. I will try to explain the design decisions that influenced the creation and current structure of moutjs and why single function packages are not always the best solution.
This weekend I spent some time improving the structure of some of my open source projects repositories and also finally decided to add a Travis-ci hook to the most active/newest ones.
It is really easy to setup it if your tests are already executed on the command line. If the tests needs a browser to work you can hook a headless browser like PhantomJS. - For my projects I’m just executing the tests on node.js for now since that should be enough to catch most errors. - Having a headless browser can help to double check if the code works on multiple environments.
Travis documentation is very clear and the amount of boilerplate is minimal, for a regular node.js project you just need a file named
.travis.yml on the root folder containing:
language: node_js node_js: 0.8
Yesterday I pushed 2 new projects to github, was unsure if I was going to do it since maintaining opensource projects can demand a lot of time but heck, I’m looking for contributors and they can be useful to more people, so why not?
I’ve been using amd-utils on almost all my projects and sometimes I find myself wanting to use some of the methods on my node.js programs as well, so I decided to write a tool to convert the modules automatically.
The tool uses Esprima internally so it will keep the indentation, comments and it should work as long as the code can be parsed by Esprima. It will do as few replacements as possible to avoid undesired side effects.
am I the only one who find it “weird” that all (popular) node.js test frameworks uses a global install?
— Miller Medeiros (@millermedeiros) October 25, 2012
On this post I will try to explain why it’s an anti-pattern and show how to avoid global installs by using
npm test instead.