module not found: empty dependency (no request)

When Webpack bundles your modules it follows the dependency chain of the module that you've imported (or required) and pulls in all of its dependencies and also bundles them all the way down to the end of the chain.

If there's a file that it doesn't know how to load in that dependency chain then this type of error will be thrown.

This can sometimes be solved by adding a loader that knows how to load this type of dependency. If, however, the dependency is a non-native module then Webpack cannot load it. Some of the loaders know how to load modules with non-native dependencies by stubbing out and excluding the non-native part so that it will load. In the fs module for example you don't need to be able to read and write files from disk because the browser cannot do that so no need to include that part.

This raises the question: What functionality from the mongoose module do you need in the browser? Can you include just that functionality and not the entire mongoose module?

If you are able to do this then you might be able to solve 2 problems:

You might solve the Webpack bundling problem because the part of mongoose that you're including in your project does not have problematic sub-dependencies.
You will be creating a smaller bundle with Webpack because you'll only be including the parts that you need so the bundle.js payload to the client will be much smaller.
As an example, I recently needed to use the mongodb ObjectId generator in the client. I discovered that Webpack was unable to cope with the import mongodb from 'mongodb' component so digging into the dependencies I found that mongodb depends on mongodb-core which depends on bson which has the ObjectId method I needed.

By importing only the bson component of that dependency chain I got around the Webpack problem and made my bundle much smaller.

If you're using Npm 3 then there's a good chance that bson is installed in the root of node_modules if you're already using mongoose or mongodb so you can import it without putting an explicit reference to it in your package.json. This obviously carries the risk that if the upper dependency stops depending on it then your build will break and you'll need to npm install it independently. The advantage of using this approach is that you will always be using the same version of bson that the upper dependency is using which might be important.