Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

factor-bundle does not close writable streams when a browserify error occurs

未关闭
  • 哪里不对？
#82 0 条评论 3 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
35/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
停滞
技术栈
javascript, node.js
领域
build-system

调研方向

链接的对比包含一个最小复现测试；先从那里开始，然后跟踪 browserify 报告错误时 factor-bundle 对输出流的处理。完成的标准是：可写输出流在错误路径上被关闭，并且回归测试不再无限期等待 finish 或 unpipe。

由索引模型根据 Issue 内容生成。

描述

I am attempting to set up a fairly complex JavaScript pipeline using browserify, watchify, babelify, factor-bundle, and eventually envify and uglifyify. Along the way I ran into issue #61 where my process was closing early and truncating the output from one of factor-bundle's streams.

Once I realized what was going on, I started working on a way to detect when factor-bundle is done with its work. I construct my own writable streams inside a function that I pass to factor-bundle's outputs argument, attaching event handlers to the finish (or unpipe) events on those streams, making each event resolve a Promise and waiting for Promise.all() to resolve.

The whole thing looks roughly like this:

var files = ['x.js', 'y.js'];
var streamPromises = [];

var b = browserify({
  cache: {}, // Required for watchify
  packageCache: {} // Required for watchify
}).
    add(files).
    plugin('factor-bundle', {
      outputs: function () {
        return files.map(makeStream);
      }
    }).
    plugin(watchify).
    on('update', function () {
      console.log('Changes detected...');
      bundle();
    });

function bundle(onComplete) {
  streamPromises.length = 0; // Clear promises before each rebuild
  b.bundle().
      on('error', function (err) {
        console.log(err.message);
        this.emit('end'); // Allows watchify to continue
      }).
      pipe(makeStream('common.js'));
  Promise.all(streamPromises).then(onComplete);
}

function makeStream(file) {
  var _resolve;
  streamPromises.push(new Promise(function (resolve) {
    _resolve = resolve;
  }));
  return fs.createWriteStream(file).
      on('finish', function () {
        console.log('Wrote ' + file);
        _resolve();
      });
}

bundle(function () {
  console.log('All streams are done');
});

It's not pretty, but it works - as long as the build is successful.

If browserify encounters an error for some reason (say, a SyntaxError in the JS you are bundling) then factor-bundle does create the writable streams, but they never fire a finish or unpipe event, or even its own 'error' event. Granted, in most use cases this sort of error would be uncaught and would end the process, auto-closing the streams in question. For use with watchify though, I manually catch the error and call this.emit('end'); as recommended here (and I'm open to correction if this is the wrong way to handle compilation errors with watchify). When I do so, the main browserify stream fires its finish and unpipe events, but factor-bundle's streams do not.

Is this a bug? I guess I expected factor-bundle to take ownership of the output streams and guarantee that they were closed whenever its work is done or aborted. I wrote a test to that effect, as a minimum repro case. As it stands now it sounds like I need to manually close all of the streams I pass to factor-bundle if an error occurs, but I'm starting to feel like I'm reaching farther into the guts of this plugin than I'm supposed to.

Related questions:

  • Is this a memory leak risk (related to #64)?
  • Is there another recommended way to knowing when factor-bundle is done (as asked in #57)?
  • Is there a recommended pattern for browserify error handling when using factor-bundle (related to #20)?

I admit I might have totally the wrong approach here - if there's something fundamentally wrong about my approach, please correct me! If this is a real issue, I'd be happy to try and track down a solution.

主要语言
JavaScript
星标
397
派生
24
30 天内没有已合并 PR

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

browserify/factor-bundle 的其他 Issue

查看 browserify/factor-bundle 的全部 Issue

相似的 Issue

更多 JavaScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。