This example assumes you have followed along with:
The outcome of the two scenarios covered below are valid for both es5 and es6.
By now you should have gotten a good grasp on the key elements at play here:
__webpack_module_cache__ which basically is a cache with the exports of each modulemodule.exports = {} before executing the module functionSo what happens if you do not directly access value but use functions to ensure all modules are loaded cached, before reading values? Should that help with the getters?
Let's find out
default export is a functionGiven these source files:
Will we end up in an infinite loop?
Yes.
moduleA.jsAs all exports are functions, and none of the modules is immediately invoking an imported function, we are safely reaching line 55.
All modules have their module.exports.default set to the correct function.
But in this case that mean mayhem:
moduleA calls moduleC which calls moduleB which calls moduleA into infinity.
Maximum call stack size exceededmoduleALet's now create a variation where moduleA exports two named functions:
Let's see what happens now:
Like in the previous example, we safely reach line 73 as we do not invoke any of the functions while requiring other files.
All modules have their module.exports correctly set and now we call moduleA.namedWithImportedValue.
This time we do not end up in infinite loop as moduleB uses a function from moduleA which returns a static value.
entry.js
_10{ _10 namedA: "a",_10 namedWithImportedValue: "abarbazb",_10}
moduleA to depend on itself!Of course, if moduleB would use a.namedWithImportedValue() in stead of a.namedA(), we would still end up in an infinite loop.
We will look at some variations on top of the examples so far to see if they make a difference.
We will visit:
dependsOnimport('./moduleA.js'))Click here to go to the next page