Skip to content
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

Doesn't seem to work with node 10 fs.promises #245

Closed
slikts opened this issue Aug 7, 2018 · 6 comments
Closed

Doesn't seem to work with node 10 fs.promises #245

slikts opened this issue Aug 7, 2018 · 6 comments

Comments

@slikts
Copy link

slikts commented Aug 7, 2018

import  { promises } from 'fs'
mock({
  test: 'file content',
})
await promises.readFile('test', { encoding: 'utf8' })

Produces: EBADF, bad file descriptor

While fs.readFileSync('test', 'utf8') works correctly.

node: 10.6.0
mock-fs: 4.6.0

@wibobm
Copy link

wibobm commented Aug 10, 2018

The last version of Node this worked on was 10.4.1

@SwinX
Copy link

SwinX commented Oct 17, 2018

Confirming this may be reproduced on [email protected] and [email protected]. Any insight about what's causing this issue and when it will be fixed?

@shadymoses
Copy link

shadymoses commented Oct 18, 2018

I'm getting a similar issue. I can successfully read the mock files using fs.readFileSync, but if I convert my operation to be async:

const fs = require('fs').promises
// inside async function
const content = await fs.readFile(file, 'utf8')

it always throws:

Error: ENOENT: no such file or directory, open 'src/client.jsx'

I'm using [email protected], [email protected] and [email protected].

@maxwellgerber
Copy link
Contributor

So a little insight into what's causing the issue:

mock-fs works by overloading Node's process.bindings for the internal C++ FS module. So, you call require('fs').someMethod and that someMethod calls process.bindings('fs').someMethodInternal in turn. After a mock is spun up, the fs module calls into mock-fs instead of the C++ code, allowing us to alter the behavior. Because the lib is tightly coupled to internal APIs, there's no guarantee that it will continue to function on new versions.

[NOTE: This is being phased out entirely in Node 11 due to the deprecation of bindings]

The fs.promises module isn't a wrapper around the original fs module. It does its own thing, and interacts with the underlying process bindings differently. The lib hasn't been updated to handle this new behavior, which is why people get errors when using fs.promises but not with util.promisify(fs.someFunction).

You can see the javascript-land code for fs.promises here.

The biggest change is that there's a symbol passed in to the callback param of the Binding function called kUsePromises. Conceivably, we could check for that symbol inside mock-fs here and respond appropriately. I haven't spent enough time on it to say whether or not some other issues might come up.

Feel free to take a crack at it and open a PR!

@shadymoses
Copy link

shadymoses commented Oct 18, 2018

@maxwellgerber Thanks for the info! If I can find some free time soon I'll look into that.

The weird thing is that I have another test suite that's using fs.promises to walk a directory and extract paths of files matching specific types. It's using readdir and stat from fs.promises and it's passing with mock-fs. It only seems to fail on read or write attempts.

@tschaub
Copy link
Owner

tschaub commented Feb 4, 2019

This should be addressed on the 4.8.0 release (thanks @huochunpeng, see #260).

@tschaub tschaub closed this as completed Feb 4, 2019
travi added a commit to form8ion/javascript-scaffolder that referenced this issue Apr 13, 2019
obahareth added a commit to obahareth/are-you-es5 that referenced this issue Jun 27, 2019
This fixes all tests on my machine, there was previously an issue with mock-fs with fs.promises that was affecting our tests.

tschaub/mock-fs#245

Let's 🙏 this fixes the broken tests on CircleCI.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants