Can't require files with mocked filesystem

[xavdid]

Hey there!

So I'm having sort of a weird problem. I'm testing a function that reads from a file and does stuff with the contents. I'm using mock-fs and everything is great. However, one of the modules I'm using changed their code so that there are require statements in functions that get called during the test (in my case, an HTTP request). When the mock is active, require('./blah') fails because unless I've mirrored that file (which lives > 3 levels down in node_modules), it's not found. More specific examples are here.

Is it currently possible (or possible to add) an option so that the fs is mocked as normal, but all calls to require are untouched?

[tschaub]

I agree that it would be nice if require would still use the real filesystem in this case. If anybody comes across this and is interested in digging to see if there would be a reliable way to make this work, I'd welcome suggestions. I won't have time for it in the near future, but will dig a bit when I get the chance.

[xavdid]

I've been taking a look, but there's a lot of code and I'm not sure I know enough js at this point to make a dent. In any case, here's my (truncated) stacktrace:

    Error: ENOENT, no such file or directory '/Users/david/projects/heroku-config/node_modules'
      at Binding.<anonymous> (node_modules/mock-fs/lib/binding.js:866:13)
      at maybeCallback (node_modules/mock-fs/lib/binding.js:41:17)
      at Binding.lstat (node_modules/mock-fs/lib/binding.js:863:10)
      at Object.fs.lstatSync (node_modules/mock-fs/node/fs-6.0.0.js:887:18)
      at Object.realpathSync (node_modules/mock-fs/node/fs-6.0.0.js:1522:21)
      at require (internal/module.js:20:19)
      at Heroku.request (node_modules/heroku-client/index.js:9:19)

the line that's calling it can be found here

I'm not sure that there's access to the actual fs while in the fs-6.0.0 file, so it's hard to say if it's possible at all.

[tschaub]

@xavdid if you are able to give the change in #139 a try, I'd appreciate feedback on whether that works for your case.

I think this is good default behavior. Because it would break cases where people actually wanted to require() mocked files, this would need to be a major version bump.

[xavdid]

Awesome, this works like a charm!

As for the major version bump, we could get around it by adding realRequire or similar as an option, assuming the options object is available when building the new bindings.

Hopefully there's some way to conditionally include the old behavior (though I think your patch is the better default). I'd even be happy with the new behavior locked behind an option as long as it's reachable.

[tschaub]

Ok, I dug a bit further into this. I think the current behavior around require() is buggy at best and the change in #139 should be considered a bug fix. As it is currently, after setting up a mock filesystem, you can only require() mock files that also exist in the real filesystem. This is because Node's module.js uses functions from both the fs module (which are mocked) and functions from the fs binding (which are not mocked for the module.js module, only the fs.js module).

So I'm going to publish the changes in #139 as part of a minor release.

[timkendrick]

Is there any way you can require() files from the mock filesystem then?

Context: I'm trying to write tests for a library that internally uses require() to load a webpack configuration from a user-provided webpack.config.js file. I'd like to be able to test this with a variety of mock config files – is this possible using mock-fs, or do I have to create these files in the real filesystem? Thanks!

[tschaub]

@timkendrick if you want to test the behavior of require(), others have suggested https://github.com/thlorenz/proxyquire.

This module is about providing an in-memory filesystem for the functions in the fs module. The require() function uses more than the functions in the fs module to load files.

[timkendrick]

Thanks @tschaub, that sounds perfect!

[xavdid]

Hey, just revisiting this. v4 looks like a great release, but it does reintroduce this issue (though that seems purposeful). I was curious about the context for the regression.

For me, I'm fine to lock into v3 for my tests, I was just wondering. Thanks for all your hard work!

[tedp]

Having the same problem with versions after 3.11.0. Would be good to know why this fix was reverted.

I'm having this issue too. Very annoying...

[amerryma]

Unfortunately I can't use v3 right now as I'm using node 8.6. Any updates on this?