Excluding files from preprocessor

In my current code base I keep all files (including tests) for a module/component in the same folder, e.g.

The problem is that I want test coverage for the module. Before I moved the specs into the module folder I used the following preprocessor:

preprocessors = {
    '**/resources/javascript/**/*.js': 'coverage'
};

Naturally that don’t work anymore since it also includes all my tests (thereby increasing my code coverage metrics by quite a bit). As all the tests are named *Spec.js it should be quite simple to exclude them, but I can’t seem to find a way given how the preprocessors are currently specified.

Excluding stuff when globbing appears to be quite difficult. Would it be possible to give the preprocessor an array of files instead? That would enable me to do the exclusion logic myself. Any thoughts on how this can be solved?

[lazd]

Here’s a complex example that combines a number of techniques found in various threads on the topic.

Imagine we have the following extermely contrived folder structure:

└── src/
    ├── index.js
    ├── index.js.text
    ├── index.test.js
    ├── README.txt
    ├── startuptest.js
    ├── lib/
    |   ├── util.js
    |   ├── util.test.js
    |   └── filters/
    |       ├── kalman.js
    |       └── lowpass.js
    ├── test/
    |   ├── main.js
    |   └── lib/
    |       ├── filters.js
    |       └── util.js
    └── vendor/
        ├── jquery.js
        └── three/
            ├── three.js
            └── three.fps.js

And we’d like to preprocess all files that end with .js in src/ and its subdirectories, except those under src/vendor/ and src/test/ or any file in any folder containing .test. Phew!

So, we create a pattern that uses brace expansion to become two patterns, including a negation for the .test string and a .js to match only JavaScript files:

{src,src/!(test|vendor)/**}/!(*.test).js

This results in:

src/!(*test).js                     // Files in src/ that don't contain .test and end in .js
src/!(test|vendor)/**/!(*.test).js  // Files in all subfolders of src/ except test/ or vendor/ that don't contain .test and end in .js

Here’s a test for this pattern:

var Minimatch = require('minimatch').Minimatch;
var mm = new Minimatch('{src,src/!(test|vendor)/**}/!(*.test).js');

console.log(mm.match('src/index.js'), 'Should match files in src/ folder');
console.log(mm.match('src/startuptest.js'), 'Should match files in src/ folder with test in their name');
console.log(mm.match('src/lib/util.js'), 'Should match files in src/lib/ folder');
console.log(mm.match('src/lib/filters/kalman.js'), 'Should match files src/lib/ subfolders');
console.log(!mm.match('src/index.js.txt'), 'Should NOT match files in src/ folder that contain .js but do not end in it');
console.log(!mm.match('src/README.txt'), 'Should NOT match non .js files in src/ folder');
console.log(!mm.match('src/index.test.js'), 'Should NOT match files in src/ folder with .test in their names');
console.log(!mm.match('src/lib/util.test.js'), 'Should NOT match files in src/lib/ subfolders with .test in their names');
console.log(!mm.match('src/test/main.js'), 'Should NOT match files in src/test/ folder');
console.log(!mm.match('src/test/lib/filters.js'), 'Should NOT match files in src/test/ folder with .test in their names');
console.log(!mm.match('src/vendor/jquery.js'), 'Should NOT match files in src/vendor/ folder');
console.log(!mm.match('src/vendor/three/three.js'), 'Should NOT match files in src/vendor/ subfolders');

It works, but it’s not pretty to look at. I hope this helps someone.

[thepian]

I always found it odd how some people instinctively separate implementation and tests into src and test directories, or other split out assets. They are usually closely related and you end up with parallel hierarchies. Then you need IDE support to relate them again on the assumption that test and source is called the same which is pushes you towards writing a test for each class / function which leads to box ticking rather than thinking about the problem at hand. Tools should get out of the way and let you structure a project in a way that works for the problem and project at hand.