-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implicit createCwd even with createCwd: false #100
Comments
You should be able to provide the absolute path to the file you want to create. E.g. mock({'/data/foo': 'bar'}, {createCwd: false}); What would you expect the absolute path to your |
It simply should not exist. Because there is no root relation. The main issue arises if you use MockFs#fs function. Which you could mount using MountFs. Where 'foo' from Example#1 should exist in mount. |
@HatiEth can you provide a test that demonstrates the behavior you expect? I agree there could be something that needs fixing. It would be good to get more specific about the expected behavior. |
Yeah, mostly what I ment before (wrote it on phone...): createCwd does not implicitly states that it will also be used as such. So adding another placeInsideCwd or something would be good option? To keep old behaviour? Test code: (discussable, just wrote down right now)
|
Same thing happened to me: finalMockDir = {
"eslint/fixtures/config-hierarchy": {}
};
mockFs(finalMockDir, {
createCwd: false,
createTmp: true
}); This always creates the above structure inside my I think the issue is here: https://github.com/tschaub/mock-fs/blob/master/lib/filesystem.js#L15 |
It is still not clear to me what you would expect from this code: var mock = require('mock-fs');
mock({foo: {}}, {createCwd: false}); What sort of assertion would you expect to be able to make after this? |
finalMockDir = {
"eslint/fixtures/config-hierarchy": {}
};
mockFs(finalMockDir, {
createCwd: false,
createTmp: true
}); Lets say if I execute the above code, then I should be able to say fs.readdirSync(path.join(os.tmpdir(), "eslint")); // -> should not throw error. currently this will throw error. |
@gyandeeps - you'd need to provide the full path to var assert = require('assert');
var path = require('path');
var mock = require('mock-fs');
var fs = require('fs');
var os = require('os');
var dir = path.join(os.tmpdir(), 'new-directory');
assert.throws(() => fs.accessSync(dir));
mock({
[dir]: {}
});
assert.doesNotThrow(() => fs.accessSync(dir));
mock.restore();
assert.throws(() => fs.accessSync(dir)); Using just those same modules (i.e. no mocha, no mountfs, etc.), I'm still not clear what someone would expect to be able to assert after doing this: mock({foo: 'bar'}, {createCwd: false});
// what would you be able to assert here? Currently, you can assert this: assert.doesNotThrow(() => fs.accessSync(path.resolve('foo'))); But it sounds like @HatiEth might expect that to throw instead. |
Well what would be the most obvious result to expect? The file is inaccessible. I would not expect anything thrown on your side, if it is documented properly. But on fs side i would expect an error to be risen - because the file is destined to not exist. |
While tinkering with mountfs and mock-fs combination, I discovered a weird behaviour of mock-fs.
Following code will create the
process.cwd()
even if not so desired by using theoption.createCwd = false
Currently my solution is using a root directory - but that's one extra indentation :/
This behavior seems counter intuitive, especially if you want to use the mockfs#fs functionality.
The text was updated successfully, but these errors were encountered: