For every file change or batch of file changes, wallaby.js uses the following processing pipeline:

Wallaby.js compilers and preprocessors are simple stateless functions that take a file argument and are supposed to return processed content along with some other related data. It is not recommended to keep any state between function calls because preprocessors and compilers may run in different node processes.

Postprocessor is a function that runs for every batch of file changes after all compilers and preprocessors. It has access not to just one file, but to all files (compiled and preprocessed, as well as original ones). It is also guaranteed to always run in the same node process, so it can keep some required state.

Considering all of the above, postprocessor is an ideal place for something like a module bundler, or anything else that needs to keep some state between test runs and have access to all files at the same time.

From the implementation prospective, postprocessor is a function that takes a single argument and is supposed to return a promise.

 module.exports = function () {
   return {
     files: [

     tests: [

     postprocessor: function (wallaby) {
       return new Promise(
         function (resolve, reject) {
            try {
              // postprocessor work here
              // ...

              // resolve when the work is done
              // or reject on errors

            } catch (err) {

The function argument is the wallaby.js context where you can find some properties and functions to control emitted test files. Here is a list of the argument properties and functions:

The file objects inside allFiles, affectedFiles and affectedTestFiles have the following structure:

File objects passed to the createFile function as an argument should have the following structure:

For examples on how to write your own postprocessor, look into the wallaby.js postprocessor for webpack, browserify, or wallaby-angular-filesort.