Slow rebuilds

[codymikol]

Slow rebuilds

[aaronjensen]

check out https://www.npmjs.com/package/karma-webpack-with-fast-source-maps https://github.com/aaronjensen/karma-webpack

our builds run in a few hundred ms, and it only runs the tests it needs to

[vojto]

It shouldn't be that hard to implement. Just need to somehow hook into Webpack's incremental building (what happens when you run --watch). I'll give it a try when I find some time.

[tarjei]

You, my friend @aaronjensen, is the best thing since the invention of electricity!

I'm really looking forward to the day four fork is merged into webpack-karma mainline.

Great work!

[kevinold]

I'm seeing the same issue. I have sourcemaps enabled so I know there is a performance hit there. I'm seeing 10-15s build times for about 40 files and of course their required node modules. I'd love to take advantage of a vendor bundle like I do in production but doesn't seem supported.

[vojto]

I'm currently at 5s. It's really frustrating. How is everybody esle dealing with this?

[jhollingworth]

I gave up and moved to node with jsdom. so much nicer

[leoselig]

+1
The rebuild time is unacceptable for a typical TDD workflow
We are experiencing this even in a medium sized project

[eknuth]

Would definitely love to see this!

[eknuth]

Sorry intended to comment with my workaround. I am running weback with --watch as a separate process and not using karma to build :(

[eknuth]

@aaronjensen that is incredible, thank you so much!

[aaronjensen]

You bet.

[leoselig]

Nice!
Any chance this becomes a PR soon? :)

[aaronjensen]

@leoselig maybe, @sokra is on vacation, we can discuss when he gets back. I'd love to have it in, but it removes some features (that don't appear to work any way-- #77)

[aaronjensen]

also, part of it is a pull already: #76

[necolas]

That's really nice @aaronjensen! Thanks. I ended up using your fork and creating a helper function to encapsulate the entry file boilerplate it depends on. Our entry file looks a bit like this:

const hotLoader = require('./tools/hotTestLoader')
hotLoader(require.context(/* etc /*))

[necolas]

@aaronjensen FYI, your package stopped working from karma@>=0.13.11. (Your repo doesn't have issues enabled).

[aaronjensen]

@necolas It works for me w/ 0.13.15. What problem are you seeing?

[necolas]

When a file changes, it reruns 0 tests with every version of karma >= 0.13.1. I've moved the boilerplate into a function that is called with the webpack require.context.

// hotloader.js
module.exports = function hotLoader(context) {
  const __karmaWebpackManifest__ = [];

  function inManifest(path) {
    return __karmaWebpackManifest__.indexOf(path) >= 0;
  }

  let runnable = context.keys().filter(inManifest);
  // Run all tests if we didn't find any changes
  if (!runnable.length) { runnable = context.keys(); }
  runnable.forEach(context);
};

// entry
hotLoader(require.context(...))

[aaronjensen]

@necolas sorry, can't reproduce. Try the most simple case in your entry:

const __karmaWebpackManifest__ = [];

require('./specHelper');
const testsContext = require.context('.', true, /\/(?!(flycheck))[^/]+\.spec$/);

function inManifest(path) {
  return __karmaWebpackManifest__.indexOf(path) >= 0;
}

let runnable = testsContext.keys().filter(inManifest);
if (!runnable.length) {
  runnable = testsContext.keys();
}

runnable.forEach(testsContext);

[aaronjensen]

Actually, yes, I believe that's what the problem is. I actually replace __karmaWebpackManifest__ with the actual manifest in webpack, so moving it out of your entry probably won't work.

[necolas]

Hmm, it had been working and works with some versions of Karma.

[necolas]

Tried inlining everything in my entry file and I have the same problem. I'm using webpack 1.12.2

[tarjei]

@aaronjensen would it be possible to add a way to signal to karma (via a kill signal or some http url) so that I can get karma to run all the tests without restarting karma?

[eknuth]

@tarjei touching or saving your test entry point will run all the tests.

[maksimr]

@aaronjensen https://www.npmjs.com/package/karma-webpack-with-fast-source-maps is a great plugin which really speed up tests. I think it should be part of karma-webpack.
What do you think?

[aaronjensen]

@maksimr i'm all for it, I just haven't had a lot of time to make it so. I'm also still not entirely clear on some of the changes I made, like with the multiple configurations.

[maksimr]

@aaronjensen I see. My opinion If you push current solution to the karma-webpack we can understand what people use and community will faster fix karma-webpack then your fork. Maybe they simple does not use multiple configuration. :)

Thanks

[joshwiens]

//cc @MikaAK

[lucassus]

It's not directly related to karma-webpack but this https://github.com/lucassus/angular-webpack-seed/pull/51/files PR demonstrates how I workaround slow rebuild problem.
Basically in the first terminal I run webpack watcher, in the configuration I have two chunks - vendor, app + specs and in the second terminal I'm running karma watcher against the generated files.

Rebuild speed in this case is almost x5 better, perfect for TDD ;)

[tarjei]

Very interesting!

2016-11-17 13:35 GMT+01:00 Lukasz Bandzarewicz [email protected]:

It's not directly related to karma-webpack but this
https://github.com/lucassus/angular-webpack-seed/pull/51/files PR
demonstrates how I workaround slow rebuild problem.
Basically in the first terminal I run webpack watcher, in the
configuration I have two chunks - vendor, app + specs and in the second
terminal I'm running karma watcher against the generated files.

Rebuild speed in this case is almost x5 better, perfect for TDD ;)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#54 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAM5PxNcQb3WdBDpOQzqfMfjCwXJpMrnks5q_EodgaJpZM4FEZuQ
.

---

Tarjei Huse
Mobil: 920 63 413

[pjtatlow]

@aaronjensen Is there any hope of your changes in karma-webpack-with-fast-source-maps getting merged into karma-webpack? It seems like it's been a while and I want to know if there's anything I can do to help.

[aaronjensen]

@pjtatlow We don't use Karma anymore and I believe karma-webpack has changed a bit since my fork. I'm sure they would welcome a PR w/ my changes to the current karma-webpack.

[GalitTugi]

@aaronjensen 's solution worked for me!
from 18-20 seconds the rebuild scaled down to about 1s!!
The solution for me was in this link: https://github.com/aaronjensen/karma-webpack

Thanks @aaronjensen !

[fzxt]

I'm currently running webpack-dev-server on the side to build my test bundle then telling Karma to watch the output bundle for changes.

[dannybloe]

Any news regarding this problem? It is almost impossible for me to have karma watch for changes as recompiling takes ages. It's always faster to just break and restart the tests.

[maksimr]

@dannybloe we are currently using this workaround

karma.config.js

  webpackConf.plugins = webpackConf.plugins.concat(
    (new class {
      apply(compiler) {
        const name = 'YouTrackKarmaAffectedTestsPlugin';
        const {ConcatSource} = require('webpack-sources');
        compiler.hooks.compilation.tap(name, compilation => {
          compilation.hooks.optimizeChunkAssets.tap(name, chunks => {
            const affected = compilation.modules.reduce((affected, module) => {
              if (module.built && !affected.has(module.id)) {
                affected.add(module.id);
                const queue = module.reasons.map((reason) => reason.module);
                while (queue.length) {
                  const module = queue.shift();
                  if (module && !affected.has(module.id)) {
                    affected.add(module.id);
                    // eslint-disable-next-line max-depth
                    for (const reason of module.reasons) {
                      queue.push(reason.module);
                    }
                  }
                }
              }
              return affected;
              // eslint-disable-next-line no-undef
            }, new Set());


            const karmaWebpackManifest = JSON.stringify(Array.from(affected));
            for (const chunk of chunks) {
              for (const file of chunk.files) {
                compilation.assets[file] = new ConcatSource(
                  `this.karmaWebpackManifest = ${karmaWebpackManifest};`,
                  '\n',
                  compilation.assets[file]);
              }
            }
          });
        });
      }
    }())
  );

test-bundle.js

const testsContext = require.context('../../app', true, /test\/(?!e2e\/).*\.js$/);
const allTests = testsContext.keys();
const affectedTests = global.karmaWebpackManifest ?
  allTests.filter((path) => global.karmaWebpackManifest.indexOf(testsContext.resolve(path)) >= 0) :
  null;

(affectedTests && affectedTests.length ?
  affectedTests :
  allTests).forEach(testsContext);

So this code allows us to run only tests affected by changes.

global.karmaWebpackManifest- This global variable contains a list of files affected by changes. We inject this variable by webpack plugin (described above)

[dannybloe]

Mm, looks complicated 😉
Does this solve the issue where, upon a code change, Webpack quickly runs to 89% of the compilation process and then seems to wait for a couple of minutes before it continues (and run the tests)?

[codymikol]

I'll test this on a large project and see if there is still a significant slowdown.

[codymikol]

As karma is now deprecated and coming up on EOL, we are no longer planning on any significant enhancements to this project and are instead going to focus on security updates, stability, and a migration path forward as karma's lifecycle comes to an end.

Thank you for supporting and using this project!