from2 generates a readable stream from a function, this can be easily replaced by native Node JS code
This will save you a dependency and make your code more future proof

For simple iterators there is stream.Readable.from(iterable[, options]) since Node 10.17.0

For more complex cases one can use async generators. E.g. see https://2ality.com/2019/11/nodejs-streams-async-iteration.html

If your project depends on a third party module that still uses from2 and you wish to the features of a modern readable stream (e.g. async iteration) then you can use:

const legacyStream = thirdPartyStreamUsingFrom2
const modernStream = (new Readable({objectMode:true}).wrap(legacyStream))

Hope this helps someone ;-)

Just tried your string example and I get:

node_modules/from2/node_modules/readable-stream/lib/_stream_readable.js:520
  dest.on('unpipe', onunpipe);
       ^
TypeError: Cannot call method 'on' of undefined

'use strict'

var from = require('from2')
var tick = 0
var stream = from.obj(function (size, cb) {
  cb(null, {tick: tick++})
})

stream.once('data', function (data)  {
  console.log(data)
})

setTimeout(function () {
  process.exit()
}, 1000)

Expected behavior to print out {"tick": 0} and for the process to exit after 1000 milliseconds, instead the process never exits because the (infinite) from stream is blocking the event loop (even though we use once)

I try it and get infinite loop in headStream

var headStream = from2.obj(function (size, next) {
    var file = new File({
        path: 'head.js',
        contents: new Buffer('head content')
    });
    next(null, file);
})

series(headStream, otherStream)
    .pipe(g.concat(name))
    .pipe(gulp.dest(destPath))

I try it and get 16 loops (size = 16), but head file doesn't write to output file

var flag = false;
var headStream = from2.obj(function (size, next) {
    if (flag) return this.push(null);
    ...
    flag = true;
    next(null, file);
})
...

If I use through it works!

var headStream = from2.obj(function (size, next) {
    ...
    this.push(file)
    next();
})
.pipe(through2.obj(function (file, enc, callback) {
    callback(null, file);
}));
...

Why? And how to do it without through?

stream errors are tricky. I always forget to test for them. from2 would be super handy if it could emit error if an Error object is introduced in the array. For example

from2.obj([
  {a: 1},
  new Error('oooops'),
  {a: 2}
]).on('error', console.log)
 .pipe(ndjson.stringify())

I can take a crack at this, as I believe I would just add a contains instance of Error in the check function
https://github.com/hughsk/from2/blob/master/index.js#L57

@mafintosh does this sound reasonable?

Calling next seems to re-call the read function immediately, adding to the call stack. This limits the logic you can put into the read function,

For example, the below program ends up throwing RangeError: Maximum call stack size exceeded, rather than adding a single character to the stream and then outputting Hello to the console.

var from = require('from2');
var source = from(function(size, next) {
  next(null, '-');
  next(null, null);

  // Never gets here
  console.log('Hello');
});
source.read();

I'm certainly not an expert on Node streams, but this seems unexpected to me.

Edit: Tweaked the code to make it slightly more realistic

I use your library to wrap internally an async method.

The problem that I detected is related when the case that I need to add more than one chunk of data in the same read call. Check this code:

return from(function (size, next) {
    if (hashFetch()) {
      fetchTweets(function (err, tweets) {// 'tweets' is an array

        next(null, tweets) // works but the final output is { [], [], []}
        // We need something like {[, , , ]}

        tweets.forEach(function (tweet) {
          next(null, tweet) // FAIL, EOF stream!!!!! also with setImmediate
        })

the solution was this:

          // trick to avoid push undefined
          var lastTweet = tweets.pop()
          tweets.forEach(function (tweet) {
            _this.push(tweet)
          })

          next(null, lastTweet) // necessary to avoid push 'undefined'

view source

for me it's ok, but do you think that could be possible support internally this?
Is necessary put undefined under next() call?

It's not documented anywhere.

Hello! I've noticed that streams created with this library do not support async iteration. This appears to be because it depends on readable-stream v2.x.x, and Symbol.asyncIterator was added to that library in v3.x.x, when it started supporting Node v10. I noticed in #21 that there was reluctance to upgrade to readable-stream v3.x.x, but that was more than a year and a half ago.

Would you be open to a PR that updates the dependency? Or does that issue still remain? Alternatively, any suggestions for how I might support async iteration in streams created by this library?

I'm the author of fetch-timeline that uses your library yo fetch user timeline from Twitter :D

I detected a case of use where is not possible listen for event different than data if you don't listen data first. Check this tests:

    timeline
      .on('data', function () {}) // necessary to be possible access rs stream :-(
      .on('err', done)
      .on('fetched', function (fetched) {

code source

Could be possible adapt how to expose the readableStream to avoid it?

summary
I think we should loosen the close signature of next(null, null) to also accept next(null, undefined).

motivation
Intuitively I assumed the closing signature would be next(null), as is the case with stream.Readable which requires this.push(null) to close a stream. I found it confusing that the signature was instead next(null, null).

detailed design
Probably all that needs to happen is change a strict index.js#L62 from if (data === null) to if (!data).

drawbacks
The only caveat I can think of with a falsy check is that doing cb(null, 0) won't work, but that shouldn't be an issue with streams (e.g. it's generally only buffers / strings / objects).
Maybe a slight impact on performance would happen (falsy check over strict equality OR an extra if statement), but I think the overhead would be negligable.

What do you think?