Repository navigation
Why does module.js directly use the process bindings instead of fs? #4190
Description
Activity
The reason is performance, see commits 98649fd...1bbf8d0 and a71ee93.
Ahh... I afraid of that.
This leads to the interesting situation that a non-existant module can't be mocked, but an existing one easily can. It would be nice if there was a way around this, any ideas? Currently, I have a directory of empty files for the purpose of mocking them out 😢.
I don't think there's an easy way around that. Maybe
module.Module#_compile(code, filename)?@MauriceButle: Unfortunately neither of those work (rooty looks useful though), I ended up with a directory of empty js files to mock out. Thanks though!
@ariporad Can we close this?
@bnoordhuis: Oh yeah, I forgot. Sorry.
Hi Node Core Team!
First of all, Thanks so much for making such an awesome thing!
Second, I'm currently working on developing something to make hooking require easier, it's called pirates. (I think very strongly that the node core should have an official way of hooking require, as it's a rather common thing to do, and very frequently done wrong, and maybe even worth bending the rules for 😉, but I know the module system is locked and off limits, so...).
As of right now, I'm trying to improve the tests (see danez/pirates#5). I wanted to do this with
mock-fs, which overrides some methods of the fs module to be backed by a memory-based file system.However, I discovered that module.js uses the fs binding directly to detect if file exist, despite using fs to actually read the file. I'm sure there's a good reason behind this that I'm just not smart enough to figure out, but for learning purposes, what is it? If there's no reason, would anyone object to me switching it (assuming the tests pass, of course)?
Thanks!