Problems with require.cache

[jhnns]

Since version 0.5.10 webpack requires every loader in a new "context" by removing all modules from cache and readding them after the loader has been executed.

I think it's very delicate to mess around with require.cache because this can lead to totally unexpected behavior. Is there are an important reason why you've introduced this?

Currently I have to lock webpack at version 0.5.8 because it breaks my code.

[sokra]

I've done this because it failed reloading loaders when in watch mode and a loader has changed.

It can fail if you rely on require in a loader return the same instance as a require not in a loader.

Multi process compiling is on roadmap and this will make these loaders fail too.

Why exactly do your code fail?

You can stay locked at 0.5.8 until we have a solution. I'm on vacation for a week by now, sorry.

[jhnns]

My module nodeclass takes so-called descriptor-objects and creates a class function. Defining a class looks like:

var MyClass = new Class("MyClass", {
    Extends: require("./MySuperClass.class.js"),
    init: function () {}
});

In order to compute all inherited properties I have to save every descriptor in a registry. Now the registry can't save those descriptors because it is created from scratch for every new class.

I think it's ok that webpack needs to be restarted if a loader has changed. Changing a loader is not the same like changing a module that will be bundled.

Currently webpack removes the whole cache before every single file. This is almost like starting a new process for every file.

[sokra]

Hmm.. i should undo this change and make multi process building as opt-in (per loader) feature. Webpack should throw an warning or an error if a loader is changed.

[jhnns]

I'm glad that I could convince you 😆