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

Outputs warning: (node:84425) ExperimentalWarning: The fs.promises API is experimental #63

Open
paleite opened this issue May 9, 2018 · 10 comments

Comments

@paleite
Copy link

paleite commented May 9, 2018

Hello,

Since Node v10.1.0, this package throws the warning (node:84425) ExperimentalWarning: The fs.promises API is experimental.

Test case:

var fs = require('mz/fs')

fs.exists(__filename).then(function (exists) {
  if (exists) // do something
    console.log('it exists') // Works
})
@dex4er
Copy link

dex4er commented May 10, 2018

How to troubleshoot this:

$ node
> process.emitWarning = () => { throw new Error('foo') }
[Function]
> require('mz/fs')
Error: foo
    at process.emitWarning (repl:1:37)
    at Object.get [as promises] (fs.js:84:15)
    at /Users/dexter/src/project/node_modules/thenify-all/index.js:62:31
    at Array.forEach (<anonymous>)
    at promisifyAll (/Users/dexter/src/project/node_modules/thenify-all/index.js:59:23)
    at Function.withCallback (/Users/dexter/src/project/node_modules/thenify-all/index.js:33:10)
>

in fs.js there is:

Object.defineProperty(fs, 'promises', {
  configurable: true,
  enumerable: true,
  get() {
    if (warn) {
      warn = false;
      process.emitWarning('The fs.promises API is experimental',
                          'ExperimentalWarning');
    }
    return promises;
  }
});

so it is problably because thenify-all tries to promisify promises lazy property.

@LinusU
Copy link
Contributor

LinusU commented May 10, 2018

There is a fix to Node.js up here: nodejs/node#20632

Will probably released in 10.1.1 or 10.2.0

We could potentially work around it here as well though...

@RyanZim
Copy link
Contributor

RyanZim commented May 10, 2018

JFYI, we fixed this in fs.extra with a getter property: jprichardson/node-fs-extra#578.

@p3x-robot
Copy link

hello, is it possible to use for all mz/fs to use the native nodejs fs.promises ?
they use native C++ promises, so much faster then any npm based promise

@p3x-robot
Copy link

it looks like all mz/fs is using require('thenify-all')....

@LinusU
Copy link
Contributor

LinusU commented May 13, 2018

hello, is it possible to use for all mz/fs to use the native nodejs fs.promises

I was thinking this as well, but we should probably wait until it's not experimental though. Not nice that it always logs a warning...

@p3x-robot
Copy link

oke, awesome, thanks! take care...

@benjamingr
Copy link

Bluebird promisifyAll is currently faster than native fs.promises but not by much fwiw.

@RyanZim
Copy link
Contributor

RyanZim commented May 16, 2018

fwiw stands for "For What It's Worth"

@benjamingr
Copy link

@p3x-robot first of all - I don't enjoy this interaction style. If something I'm saying is unclear please point it out and I will gladly explain it. Calling it 'weird' doesn't help.

I'll give some context - I am a core team member of both Node.js and bluebird and I'm very conscious about the performance of promise operations. We are having a Node.js core summit at the end of this month and are going to discuss promise performance at it.

I'm preparing some use cases and measurements for a workshop whose purpose is to discuss promise performance with the Node core and V8 so I have recently had the chance to measure this.

Bluebird is often faster (and V8 users it in their benchmarks to measure their own promise performance) because it was written from the grounds up to be fast and utilize every optimization technique that existed then with deep familiarity with how V8 works and the JIT.

There is absolutely no reason JS code should be slower than C++ code on V8 for this sort of thing in principle. Making the C++ as fast as bluebird (and faster) is ongoing work the V8 team is doing and they've closed a large portion fo the gap.

I encourage you to check some resources on how JIT compilation works and how bluebird utilizes it. A lot of the optimization tricks the current V8 implementation does also borrow from things bluebird did (and other libraries before it!).

I also encourage you to measure this yourself for your own use case (and if you make a meaningful application benchmark out of it that measures real-world performance - I promise to help you get it included in what we test performance with in Node.js).

In addition - if you have any diagnostic or debugging use cases you think Node.js can be better with - then please do bring them up (here or in @nodejs/promise-use-cases).

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