how to bust @providesModule cache

Question

I'm building a REST API that will live in AWS Lambda. I'm using apex to deploy it, and since I'm implementing it in javascript, I'm using webpack and babel to get my ES6+ goodies. I've discovered a problem with respect to @providesModule names, and I haven't been able to work around it.

I just created a new lambda function, and when I compile it, I can see from the output that one module couldn't be found -- but the other one can. Here's a sketch of the filesystem:

functions
   ├─ database.js        @providesModule Database -- this works
   ├─ configuration.js   @providesModule MyConfig -- this does not work
   ├── entity-post
          ├── index.js   imports both 'Database' & 'MyConfig'

When I compile the lambda, the output indicates that the MyConfig dependency couldn't be resolved, but that Database could be. I've tried replacing the content of configuration.js with dead-simple code, in case resolution is failing on a basic parse error; no luck. I should add that I've got 5 other lambda functions in the same project that use similar imports, and they all work great.

I assume this is some kind of caching problem: the module resolution system hasn't noticed the @providesModule inside configuration.js .

How do I clear that cache? For that matter, which piece of software is even handling these resolutions? I've tried looking around online, but it's not clear whether recognition of @providesModule is a webpack thing, or a babel thing, or a webpack-babel-loader thing, or maybe just a node v5 thing.

---

I've done a lot of digging, both online and within my project's codebase. Here's what I've learned:

Almost all of the links you'll see online about @providesModule are about react or react-native projects. That's because Facebook's tooling -- specifically HasteMap (I think), part of the react-native packager suite -- explicitly adds support for @providesModule . My project is neither react nor react-native, and it doesn't use any Facebook tools in the build process. My project uses webpack v1.14 and babel v6.22 to build the source.

I've found the error message within webpack's source, at ./node_modules/webpack/lib/dependencies/WebpackMissingModule.js :

exports.moduleCode = function(request) {
    return "var e = new Error(" + JSON.stringify("Cannot find module \"" + request + "\"") + "); " +
        "e.code = 'MODULE_NOT_FOUND'; " +
        "throw e;";
};

Webpack seems to have a term for scripts that declare a module name in this way: 'Labeled Modules'. There are several scripts within webpack's source that deal with labeled modules, but I haven't been able to pin down the code that recognizes a label within a module. My assumption is that the problem exists in the part of the system that populates the module registry, and the labeled module code I've found all seems to be related to accessing those modules within the (already populated) registry.

It's hard to trace this much further within webpack's source code, which is understandably very meta, and distributed across a bajillion files.

Any help troubleshooting this, or links to relevant documentation or framework code that shows how @providesModule is handled, is appreciated. I want to understand why my new module isn't resolving, so I can fix that problem. If my caching theory is off-base, fine.

Answer 1

This may not come as a surprise to most, but webpack doesn't (currently) honor @providesModule directives.

The reason it appeared as though it did is that webpack seems to flatten case when doing filename comparisons, and my filenames generally match the labels that I give them:

• database.js == @providesModule Database
• assemble.js == @providesModule Assemble

The reason I ran into trouble is that configuration.js != @providesModule MyConfig .

This also means the question I asked originally was off-base, in that I assumed resolution was failing because labels were being cached, when in fact labels were being ignored. Facebook's HasteMap may indeed use a cache, but it wasn't the culprit here.