kevinbeaty/fs-promise

[DEPRECATED] Use mz or fs-extra^3 with Promise support

fs-promise's Issues

async works with readJson but not with readFile

In the following, the last test fails, using await fs.readFile.

Error: ENOENT: no such file or directory, open './details.html'

However using await fs.readJsonworks just fine. Any idea as to why?
If I change the readJson to readFile it also fails there:

Error: ENOENT: no such file or directory, open './map.json'

require('./helper');
const fs = require('fs-promise');
const path = require('path');
const mock = require('mock-fs');

const expect = require('chai').expect;

describe('FileIO', () => {
  before(() => {
    mock({
      'map.json': `
        {
          "ui": {
            "vue": {
              "path": "./ui/vue"
            }            
          }
        }
      `,
      'details.html': `<template><h1>{{message}}</h1></template>`
    });    
  })

  after(() => {
    mock.restore();
  })    

  describe('map.json', () => {            
    it('should contain path to ui files', async () => {   
      let result = await fs.readJson('./map.json');          
      console.log('result', result);             
      expect(result.ui.vue.path).to.eql('./ui/vue');
    });
  });

  describe('ui template file', () => {            
    it('should contain template', () => {   
      let result = fs.readFileSync('./details.html', 'utf8');          
      console.log('result', result);             
      expect(result).to.match(/message/);
    });
  });

  describe('ui template file - async', () => {            
    it('should contain template', async () => {   
      let result = await fs.readFile('./details.html', 'utf8');          
      console.log('result', result);             
      expect(result).to.match(/message/);
    });
  });
});

Test Coverage

Need to greatly increase test coverage before the next release.

Does not promisify mkdtemp

> require('fs-promise').mkdtemp('test')
undefined // expected Promise

Bump to 1.0.0?

Hello, this library seems widely used, has no issue… Wouldn't it be time to allow proper semantic versionning by bumping version to 1.0.0?

Consider deprecation in favor of mz

normalize/mz#16 now incorporates any-promise. Consider deprecating fs-promise in favor of mz/fs

Include @types dependencies to "dependencies"

Why this change? 90fd3d4

fs-promise is a third party lib that must include all its dependencies in "dependencies", otherwise typescript consumers will never download the @types.

Right now (2.0.2) is broken because you depend on @types/fs-extra and @types/mz. When I compile I get an error. It doesn't find the @types/fs-extra and @types/mz definitions.

Walk removed?

Hey, the readme for the project still says that that project proxies walk from fs-extra, but walk was removed in fs-extra 2.0.0.

Do you still intend to support walk? fs-extra moved it into its own package klaw

Errors are missing stack traces (Different from #19)

Same question is asked in #19, but stack trace is missing even for non fs related errors when fs-promise is used in promise chain:

const fs = require('fs-promise');
let a;

fs.readdir('.')
  .then(files => a.invalid)
  .catch(console.log);

TypeError: Cannot read property 'invalid' of undefined at fs.readdir.then.files (/Users/ozum/Development/l10n-formatjs/sil.js:10:19)

On the other hand Bluebird or fs-extra-promise has stacks:

const Promise = require('bluebird')
const fs      = Promise.promisifyAll(require('fs-extra'));
// OR const fs   = require('fs-extra-promise');

let a;

fs.readdirAsync('.')
  .then(files => a.invalid)
  .catch(console.log);

TypeError: Cannot read property 'invalid' of undefined
    at fs.readdirAsync.then.files (/Users/ozum/Development/l10n-formatjs/sil.js:9:19)
    at tryCatcher (/Users/ozum/Development/l10n-formatjs/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/Users/ozum/Development/l10n-formatjs/node_modules/bluebird/js/release/promise.js:512:31)
    at Promise._settlePromise (/Users/ozum/Development/l10n-formatjs/node_modules/bluebird/js/release/promise.js:569:18)
    at Promise._settlePromise0 (/Users/ozum/Development/l10n-formatjs/node_modules/bluebird/js/release/promise.js:614:10)
    at Promise._settlePromises (/Users/ozum/Development/l10n-formatjs/node_modules/bluebird/js/release/promise.js:693:18)
    at Promise._fulfill (/Users/ozum/Development/l10n-formatjs/node_modules/bluebird/js/release/promise.js:638:18)
    at /Users/ozum/Development/l10n-formatjs/node_modules/bluebird/js/release/nodeback.js:42:21
    at go$readdir$cb (/Users/ozum/Development/l10n-formatjs/node_modules/fs-extra-promise/node_modules/graceful-fs/graceful-fs.js:149:14)
    at FSReqWrap.oncomplete (fs.js:114:15)

Audit vulnerabilities detected in the fspromise project on Tag: 2.0.2

Issue: We detected vulnerable dependencies in your project by using the command “npm audit”:

npm audit report

debug <=2.6.8 || 3.0.0 - 3.0.1
Regular Expression Denial of Service - https://npmjs.com/advisories/534
fix available via npm audit fix --force
Will install [email protected], which is a breaking change
node_modules/debug
mocha 0.6.0 - 6.2.2 || 7.0.0-esm1 - 7.1.0
Depends on vulnerable versions of debug
Depends on vulnerable versions of diff
Depends on vulnerable versions of growl
Depends on vulnerable versions of mkdirp
node_modules/mocha

diff <3.5.0
Severity: high
Regular Expression Denial of Service - https://npmjs.com/advisories/1631
fix available via npm audit fix --force
Will install [email protected], which is a breaking change
node_modules/diff
mocha 0.6.0 - 6.2.2 || 7.0.0-esm1 - 7.1.0
Depends on vulnerable versions of debug
Depends on vulnerable versions of diff
Depends on vulnerable versions of growl
Depends on vulnerable versions of mkdirp
node_modules/mocha

growl <1.10.2
Severity: critical
Command Injection - https://npmjs.com/advisories/146
fix available via npm audit fix --force
Will install [email protected], which is a breaking change
node_modules/growl
mocha 0.6.0 - 6.2.2 || 7.0.0-esm1 - 7.1.0
Depends on vulnerable versions of debug
Depends on vulnerable versions of diff
Depends on vulnerable versions of growl
Depends on vulnerable versions of mkdirp
node_modules/mocha

minimist <0.2.1 || >=1.0.0 <1.2.3
Prototype Pollution - https://npmjs.com/advisories/1179
fix available via npm audit fix --force
Will install [email protected], which is a breaking change
node_modules/minimist
mkdirp 0.4.1 - 0.5.1
Depends on vulnerable versions of minimist
node_modules/mkdirp
mocha 0.6.0 - 6.2.2 || 7.0.0-esm1 - 7.1.0
Depends on vulnerable versions of debug
Depends on vulnerable versions of diff
Depends on vulnerable versions of growl
Depends on vulnerable versions of mkdirp
node_modules/mocha

6 vulnerabilities (3 low, 1 high, 2 critical)

To address all issues (including breaking changes), run:
npm audit fix --force

Questions: We are conducting a research study on vulnerable dependencies in open-source JS projects. We are curious:

1. Will you fix the vulnerabilities mentioned above? (Yes/No), and why?:
2. Do you have any additional comments? (If so, please write it down):

For any publication or research report based on this study, we will share all responses from developers in an anonymous way. Both your projects and personal information will be kept confidential.

Description: Many popular NPM packages have been found vulnerable and may carry significant risks [1]. Developers are recommended to monitor and avoid the vulnerable versions of the library. The vulnerabilities have been identified and reported by other developers, and their descriptions are available in the npm registry [2].

Steps to reproduce:

• Go to the root folder of the project where the package.json file located
• Execute “npm audit”
• Look at the list of vulnerabilities reported

Suggested Solution: Npm has introduced the “npm audit fix” command to fix the vulnerabilities. Execute the command to apply remediation to the dependency tree.

References:
2019. 10 npm Security Best Practices. https://snyk.io/blog/ten-npm-security-best-practices/.
2021. npm-audit. https://docs.npmjs.com/cli/v7/commands/npm-audit.

write() callback third argument is not passed

Hi,

fs-promise very interesting to avoid callback hell. I am new to node and Promises, so may be I missed something.

The implementation of fs-promise is very clever, but I think its global approach fails with the write() function.

As stated in the doc, write() cb argument takes 3 arguments : err, written and data.
This 3rd argument is not passed to the .then handler (see example below)

Because of the Promise spec, I believe the promise value should be a single object with written and data/buffer properties. But this means handling a special case in fs-promise.

By the way, do you know of any typescript binding for fs-promise. I am ready to write one if none exists, and ideally would like to add it directly into the fs-promise project.

Olivier

function testWriteFsp() {
  fsp.open("some.txt", "w+").then( function (fd) {
    return fsp.write(fd, "hello fs-promise").then( function (written, text) {
      console.log(written,"/",text);
      return fsp.close(fd);
    })
  }).catch( function (reason) {
    console.log("Unable to write to file ",reason);
  })
}
// 16/undefined

Errors are missing stack traces

I'm not sure if this is a problem in fs-promise, or something deeper, or maybe I'm doing something wrong (probably the latter): but if a Promise.catch on a top level promise catches something from deeper inside, it's missing the stack trace.

Example code to reproduce:

const fsp = require('fs-promise');

function readFile() {
  return fsp.readFile('./doesntexist', 'utf-8');
}

function main() {
  return readFile();
}

main().catch(err => {
  console.error(err); // err has no stack trace
  console.error(err.stack) // doesn't contain stack trace, where did the error come from?
});

Would be nice to have that stack trace to figure out when things go wrong in a more complicated real-world example.

What is "file" in example snippet

Hey there, regarding this snippet from the README:

fsp.writeFile(file('hello1'), 'hello world')
  .then(function(){
    return fsp.readFile(file('hello1'), {encoding:'utf8'});
  })
  .then(function(contents){});

What is file? Sorry if this is ultra noob.

No lock file found in the fspromise project on Tag: 2.0.2

Issue: There is no package-lock.json or npm-shrinkwrap.json file uploaded to the GitHub repository https://github.com/kevinbeaty/fs-promise

Questions: We are conducting a research study on the lock files used in JS projects. We were curious:

1. Will you upload any lock files to GitHub as recommended above? (Yes/No), and why?:
2. Do you have any additional comments? (If so, please write it down):

For any publication or research report based on this study, we will share all responses from developers in an anonymous way. Both your projects and personal information will be kept confidential.

Rationale: NPM introduced package-lock.json and npm-shrimpwrap.json files to capture the exact dependency tree installed at any point in time. When package.json defines the required dependencies and their respective versions using semantic versioning (e.g., “express”: “^4.16.4”), npm always downloads the latest version of packages to satisfy the specified version ranges (e.g., 4.17.1)[1]. If the latest version of any package keeps changing and has backward incompatibility issues with previous versions, the project may have an inconsistent running environment and get intermittent failures. In such scenarios, it can be very difficult for developers to debug programs and settle down the software environment [2].

List of Risks:

• Nondeterministic package downloads and installations across different environments [3]
• Produce irreproducible builds [4]
• Inconsistent results of program execution [5]

Suggested Solution: Please fixate the dependencies by either specifying the exact library version in the package.json file or by uploading the package-lock.json or npm-shrinkwrap.json file to GitHub.

References:
https://docs.npmjs.com/cli/v7/configuring-npm/package-lock-json
https://blog.logrocket.com/why-you-should-use-package-lock-json/
2019. 10 npm Security Best Practices. https://snyk.io/blog/ten-npm-security-best-practices/.
Pronnoy Goswami, Saksham Gupta, Zhiyuan Li, Na Meng, and Daphne Yao. 2020. Investigating The Reproducibility of NPM Packages. In2020 IEEE International
2021. Npm Security Best Practices. https://bytesafe.dev/posts/npm-security-best-practices/#no9-deterministic-results.

Explicit `fs` implementation

Hi, I’m looking at your library and want to share my fresh first impressions.

😄 Great idea! Looks more lightweight than the monolithic q-io.

😕 But one thing isn’t clear to me. How do you determine whether you use fs, graceful-fs, fs-extra or something else? It feels a bit magical to me – I’d feel safer if this were explicit:

const fs = require('fs-promise')(require('fs-extra'));

Update promise library

Update the internal promise dependency from ~3.0.0 to ~4.0.0. This enables additional functions like .catch and .done on the promise objects.

Add fs-extra as dependency

The strategy of loading optional dependencies is non-deterministic as a fs-extra or graceful-fs library loaded in a subtree of the dependency tree may be loaded instead of the desired implementation. This could be caused by the non-deterministic loading of npm3, but there may have been cases in npm2 where this occurred as well. This is was also an issue in any-promise with a resolution discussed in kevinbeaty/any-promise#1

Options:

1. Add fs-extra as an explicit dependency.
2. Add graceful-fs as an explicit dependency
3. Only use fs and remove loading of optional dependencies.

Proposal:
Add fs-extra as an explicit dependency (Option 1).

Deprecate in favor of fs-extra v3

fs-extra v3 was just released with native promise support.

Here's the changelog: https://github.com/jprichardson/node-fs-extra/blob/master/CHANGELOG.md#300--2017-04-27

Switching should be pretty easy, but there's a few gotchas:

• fs-extra v3 doesn't use any-promise; only native promises are supported
• fs-promise uses mz/fs which fixes the callback signature for fs.exists. fs-extra is a drop-in replacement for the native fs, so we can't fix that. fs-extra v3 adds a pathExists() method that behaves like mz/fs's exists.

Would like to discuss the best way to deprecate this with @kevinbeaty.