Wallaby-webpack source code (out of sync and/or instrumentation) issue

[bZichett]

I'm back to using webpack 1.X (1.12.14) and although on the surface wallaby is working, there appears to be a few issues which render my unit testing unworkable. My source files are out of sync with tests and are not instrumented properly (grey squares, no test coverage) Changing a source file requires a complete reboot of wallaby, force recompiling the webpacked code.

I'm leaning towards this relating to one of the following: 1) ES6 Transpilation 2) The dev-tool option 3) Webpack aliasing (which wallaby-webpack might be failing to instrument and/or pick up on when recompiling?)

I tried most of the tips on wallaby-webpack page (trying to use wallaby's compiler and removing babel-loader, and vice versa, along with a few other config modifications) and using the three suggested devtool options but to no avail.

I mostly wanted to ask if the functionality I'm expecting is implemented by wallaby-webpack (as it was working with the require solution,) although it'd defeat most the purpose if not. If so I'll set up a smaller test case and figure out where my config is going wrong and post my wallaby and/or webpack config if I fail. (What I suspect is that if I ditch ES6 it'll work as intended.) Thanks.

[ArtemGovorov]

@bZichett Yes, the functionality you are expecting is implemented by wallaby-webpack and is working in many different projects. Please provide a smaller test case where the issue can be reproduced and we'll figure out what's wrong.

[bZichett]

I believe I'm having issues with webpack aliases and wallaby-webpack. Using relative paths resolves (haha) my issues with this method to resolve modules.

Important Edit: Below is the test case, but I also confirmed this in my real project, where notably, I don't get the error message "cannot find module," and the testing works except for the lack of sync and no instrumentation issue as posted in this thread's subject, meaning I could ditch aliases in the time being (and use relative paths in my specs) to get full use of wallaby testing and webpack. But on further thought, I believe that I'm (or wallaby-webpack) is not properly including the test files to receive the alias definitions from webpack. The alias in the test file seems to work, but it must(?) be linking to some cached file rather than the source file that needs to be instrumented. That's my best interpretation at least. Hope it helps you, Artem.

core ├── ModuleA.js └── ModuleA-test.js

import { TableOfContents } from 'core/ModuleA' // <= This fails with cannot find module ... 
// import { TableOfContents } from './ModuleA' // <= Everything works as intended (instrumentation and synchronization) using relative paths

describe('#TableOfContents', function () {

    it('generates a table of contents', function () {
        // Test ...
    })
})

var path = require('path')
var webpack = require('webpack')
var wallabyWebpack = require('wallaby-webpack');

module.exports = function (wallaby) {

    var devConfig = {
        entry: [path.resolve('core/ModuleA.js')],
        output: {
            path: 'build',
        },
        module: {
            loaders: [
                {
                    test: /\.js$/,
                    exclude: /node_modules/,
                    loader: 'babel-loader',
                    query: {
                        babelrc: '.babelrc'
                    }
                }
            ]
        },
        resolve: {
            extensions: ['', '.js', '.scss', '.css'],
            alias: {
                core: path.resolve('./core')  // Checked that this points to the right place -> /home/username/project/core
            }

        }
    }

    devConfig.entryPatterns = [
        'core/**/*-test.js',
    ];

    //Delete babel-loader
    devConfig.module.loaders = devConfig.module.loaders.filter(function (l) {
        return l['loader'] !== 'babel-loader'
    });

    delete devConfig.devtool;

    return {
        debug: true,

        files: [
            /** MODULES */
            {pattern: 'core/**/*.js', load: false},
            /** IGNORE */
            {pattern: 'core/**/*-test.js', ignore: true}

        ],

        tests: [
            {pattern: 'core/**/*-test.js', load: false}
        ],

        testFramework: 'mocha@2.2.4',

        compilers: {
            '**/*.js': wallaby.compilers.babel({
                babel: require('babel-core'),
                presets: ['es2015'],
            })
        },

        postprocessor: wallabyWebpack(devConfig),

        bootstrap: function () {
            window.__moduleBundler.loadTests();
        }
    }
};

[bZichett]

@ArtemGovorov Not sure if you got to reading my reply above, but I added an important edit which I probably should have put here.

[ArtemGovorov]

@bZichett Thanks a lot for your sample.

The alias in the test file seems to work, but it must(?) be linking to some cached file rather than the source file that needs to be instrumented

This looks like an issue. But the other way around, it's linking your local project file, but should be linking the instrumented version of the file in wallaby.js cache instead. Because otherwise the original file gets executed and it doesn't have any instrumentation instructions in it, so no coverage is reported.

This is one of few described in the docs cases when wallaby webpack config needs to explicitly point to the wallaby cache of the project.

The fix is very simple:

      alias: {
        core: path.join(wallaby.projectCacheDir, 'core')
      }

Please let me know if it works for you.

[bZichett]

That works great. I was testing out the wallaby.projectCacheDir prefix last night, but it turned out I was careless and joined it with the wrong path (I was using an externally defined reference rather than one used from where wallaby config file is.)

Have a great day and keep up the outstanding work =)

[ArtemGovorov]

Awesome, thanks for the update!