DepRes: simple dependency graph resolution

A very small, simple module that allows you to resolve dependency graphs. You can feed it with a tree or an id map and it will output an ordered array of nodes or id’s sorted bottom-up.

https://github.com/creynders/depres

Auto-loading test fixtures in node

Something which comes back time and again is the loading of test fixtures for my unit tests. This may involve a lot of boilerplate in my test files; a bunch of requires or fs.readFiles. There is however a very easy fix by using the splendid require-directory module.

As the description of the project says it …

recursively iterates over specified directory, requiring each file, and returning a nested hash structure containing those libraries.

I.e. it takes a directory, traverses its subdirectories and reads all of the files they contain and maps them to an object with the filenames as keys.

Tutorial files

I created a tutorial project with the completed files. The tutorial project already contains all dependency declarations, all you need to do is clone the repo and


$ npm install

when in the cloned repo directory.

Starting from scratch

However, if you’re starting from scratch you’ll need to install the require-directory module into your project first:

$ npm install require-directory

There are many projects with similar names, make sure you use require-directory, since that’s the one I’m interested in. Yeah, it’s a bit confusing that the project is named differently on github.

Let’s get started

Now let’s use it to load our fixtures.

For example if we got the following fixtures directory structure:

Accessing the fixtures

What we want is to be able to load all of these files into our tests at once and access them through an object.

E.g. in our tests we want to access the contents of foo/bar.json like this:

    test.deepEqual( main.awesome(), fixtures.foo.bar );

with fixtures being the object containing all of the loaded files.

Exposing the fixtures

In order to do this we need to create a fixtures/index.js file which uses node-require to load the files and exports them as an object. Like this:

//file: fixtures/index.js
var requireDirectory = require('require-directory');
module.exports = requireDirectory(module);

This file needs to reside at the root of the fixtures directory.

Using the fixtures

In our test file now we can require the fixtures directory itself:

var fixtures = require('./fixtures');

Et voila, you’re done: the fixtures object contains all files and their contents.

The full code of our test file:

//main_test.js
'use strict';

var main = require( '../lib/main.js' );
var fixtures = require( './fixtures' );

exports.tutorialLoadFixtures = {
  'awesome' : function( test ){
    test.expect( 1 );
    test.deepEqual( main.awesome(), fixtures.foo.bar, 'should be "value: Awesome!"' );
    test.done();
  }
};

Easy, isn’t it? Take a look at the tutorial project to see all the files.

Be sure to keep an eye on my blog next week, since I’ll be reviewing the “Getting started with Grunt” book by Packt!

Auto-generate modularized #grunt configuration files

I wrote a Grunt task which will take your big, fat grunt configuration object and automatically generate separate files to store the task configuration objects in: grunt-generate-configs

The task will parse your grunt configuration object and automatically create files for each task.
Continue reading

Best way to handle large grunt files

I love Grunt. Each project I’ve done last year I’ve used it to automate linting, building, testing, etc. There’s just one thing which keeps on bothering me: once a project grows, so does the grunt file. I just keep on finding new grunt plugins and adding them to my projects. With every plugin, task configuration and declarations are added to the Grunt file and its size just keeps on growing, making it very messy and hard to maintain IMO.

TL;WR (too long;won’t read)

We’re having a discussion on the best way to manage large grunt files in this thread of the yeoman generator-webapp project. Let us know what you think!

So, what’s it all about?

To me, the best way to manage grunt task configurations is by splitting it all up into several files.

I wrote a module load-grunt-configs which loads your grunt task configuration objects from files in a directory.
Continue reading

Load #gruntjs task configurations from separate files.

Grunt files tend to grow fast due to big amount of tasks and their configuration objects. I created a module load-grunt-configs that allows you to split your Grunt task configuration objects into separate files any way you choose. There are similar modules that allow you to the same, but with grunt-load-configs you can configure targets for a single task in multiple files.

This means you no longer need to group all task targets into a single file, but can split them up according to their task dependencies.

See http://creynders.github.io/load-grunt-configs/ for examples and usage.

Continue reading

Grunt-generate: a Grunt task to generate files from user-defined templates

Grunt task that generates files from user-defined templates. It follows the DFGIMW mantra (don’t fucking get in my way).

Continue reading

#Robotlegs 2 Beta 6 released

Yesterday we released Beta 6 of Robotlegs 2. Behind the scenes lots of improvements were made, aimed primarily at extension developers. But we also reintroduced some things and added a few minor functionalities:

Direct Command Map

The Direct Command Map allows you to execute commands directly and to pin and release commands in/from memory.
Continue reading

Follow

Get every new post delivered to your Inbox.

Join 545 other followers

%d bloggers like this: