HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
dominictarr
event-stream
JavaScript2012–2023
dominictarr / event-stream · Archived

event-stream

EventStream is like functional programming meets IO

24Distinct people
24Mentions
0Explicit recommenders
2.2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

EventStream is like functional programming meets IO

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:01:12 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year24 dated mentions

Observed mentions: 2012-05-11 16:20:42 UTC to 2023-05-30 05:07:38 UTC.

0510152012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20122013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 16 mentions; 3 submissions, 13 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC101
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC000
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC101
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC000
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC000
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC000
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC16313
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
EventStream Streams are node's best and most misunderstood idea, and EventStream is a toolkit to make creating and working with streams easy. Normally, streams are only used for IO, but in event stream we send all kinds of objects down the pipe. If your application's input and output are streams, shouldn't the throughput be a stream too? The EventStream functions resemble the array functions, because Streams are like Arrays, but laid out in time, rather than in memory. All the event-stream functions return instances of Stream. event-stream creates 0.8 streams, which are compatible with 0.10 streams. NOTE: I shall use the term "through stream" to refer to a stream that is writable and readable. NOTE for Gulp users: Merge will not work for gulp 4. merge-stream should be used. simple example: //pretty.js if(!module.parent) { var es = require('event-stream') var inspect = require('util').inspect process.stdin //connect streams together with `pipe` .pipe(es.split()) //split stream to break on newlines .pipe(es.map(function (data, cb) { //turn this async function into a stream cb(null , inspect(JSON.parse(data))) //render it nicely })) .pipe(process.stdout) // pipe it to stdout ! } run it ... curl -sS registry.npmjs.org/event-stream | node pretty.js node Stream documentation through (write?, end?) Re-emits data synchronously. Easy way to create synchronous through streams. Pass in optional write and end methods. They will be called in the context of the stream. Use this.pause() and this.resume() to manage flow. Check this.paused to see current flow state. (write always returns !this.paused) this function is the basis for most of the synchronous streams in event-stream. es.through(function write(data) { this.emit('data', data) //this.pause() }, function end () { //optional this.emit('end') }) map (asyncFunction) Create a through stream from an asynchronous function. var es = require('event-stream') es.map(function (data, callback) { //transform data // ... callback(null, data) }) Each map MUST call the callback. It may callback with data, with an error or with no arguments, callback() drop this data. this makes the map work like filter, note:callback(null,null) is not the same, and will emit null callback(null, newData) turn data into newData callback(error) emit an error for this item. Note: if a callback is not called, map will think that it is still being processed, every call must be answered or the stream will not know when to end. Also, if the callback is called more than once, every call but the first will be ignored. mapSync (syncFunction) Same as map, but the callback is called synchronously. Based on es.through flatmapSync (syncFunction) Map elements nested. var es = require('event-stream') es.flatmapSync(function (data) { //transform data // ... return data }) filterSync (syncFunction) Filter elements. var es = require('event-stream') es.filterSync(function (data) { return data > 0 }) split (matcher) Break up a stream and reassemble it so that each line is a chunk. matcher may be a String, or a RegExp Example, read every line in a file ... fs.createReadStream(file, {flags: 'r'}) .pipe(es.split()) .pipe(es.map(function (line, cb) { //do something with the line cb(null, line) })) split takes the same arguments as string.split except it defaults to '\n' instead of ',', and the optional limit parameter is ignored. String#split NOTE - Maintaining Line Breaks If you want to process each line of the stream, transform the data, reassemble, and KEEP the line breaks the example will look like this: fs.createReadStream(file, {flags: 'r'}) .pipe(es.split(/(\r?\n)/)) .pipe(es.map(function (line, cb) { //do something with the line cb(null, line) })) This technique is mentioned in the underlying documentation for the split npm package. join (separator) Create a through stream that emits separator between each chunk, just like Array#join. (for legacy reasons, if you pass a callback instead of a string, join is a synonym for es.wait) merge (stream1,...,streamN) or merge (streamArray) concat → merge Merges streams into one and returns it. Incoming data will be emitted as soon it comes into - no ordering will be applied (for example: data1 data1 data2 data1 data2 - where data1 and data2 is data from two streams). Counts how many streams were passed to it and emits end only when all streams emitted end. es.merge( process.stdout, process.stderr ).pipe(fs.createWriteStream('output.log')); It can also take an Array of streams as input like this: es.merge([ fs.createReadStream('input1.txt'), fs.createReadStream('input2.txt') ]).pipe(fs.createWriteStream('output.log')); replace (from, to) Replace all occurrences of from with to. from may be a String or a RegExp. Works just like string.split(from).join(to), but streaming. parse Convenience function for parsing JSON chunks. For newline separated JSON, use with es.split. By default it logs parsing errors by console.error; for another behaviour, transforms created by es.parse({error: true}) will emit error events for exceptions thrown from JSON.parse, unmodified. fs.createReadStream(filename) .pipe(es.split()) //defaults to lines. .pipe(es.parse()) stringify convert javascript objects into lines of text. The text will have whitespace escaped and have a \n appended, so it will be compatible with es.parse objectStream .pipe(es.stringify()) .pipe(fs.createWriteStream(filename)) readable (asyncFunction) create a readable stream (that respects pause) from an async function. while the stream is not paused, the function will be polled with (count, callback), and this will be the readable stream. es.readable(function (count, callback) { if(streamHasEnded) return this.emit('end') //... this.emit('data', data) //use this way to emit multiple chunks per call
Read the full README on GitHub

What Hacker News says

16 sources
I'm not sure if it's applicable, however; I'd be interested in any association that can be made against previous versions of such libraries, and the newly released open source libraries. Are the 'releases' between the old closed source and that of the newly open source significantly different? If so, and either way; I'd be interested in knowing what kind of changes were applied in direct action of the source being released. Was it just cleaning/linting of the code? Were there features that were otherwise inappropriate (security? quality?) that needed attention before release. Things like alignment with child dependency license agreements, or overall quality (in code, testing, and deployment) are things I find extremely interesting. Was there some interesting 'inappropriate' language in the source from developers long gone. Could this have
Read the rest
effectively been the opposite spectrum of what happened with event-stream https://github.com/dominictarr/event-stream/issues/116 I'm not explicitly saying it's any of my business. I can imagine a multitude of reasons that this history would never be provided. But... as above.. I can consider reasons, perhaps; it should..? I don't mean to discourage release. I really appreciate it. Just some thoughts.. Edit: Minor readability
In Announcing Open Source of WPF, Windows Forms, and WinUI
neya·Nov 30, 2018Submission

Warn HN: Malicious Package on NPM - check if you're affected

Hi HN, As a user of OnsenUI, I came across something bizarre today. Running `npm install` lead to a warning and on further investigating, revealed there was a malicious package stuck inside my installation. Running `npm audit` showed the following info: Critical: Malicious Package Package: flatmap-stream Patched in: No patch available Dependency of: onsenui Path: onsenui > gulp-protractor > event-stream > flatmap-stream More info: https://nodesecurity.io/advisories/737 What exactly happened? Apparently the maintainer of `flatmap-stream` gave write access to his repo to a random guy claiming to want to maintain the package. Both of them have been rid off write access as of now. I have since reported this issue to OnsenUI community: https://github.com/OnsenUI/OnsenUI/issues/2592 If you're using this in production, please watch out. More det
Read the rest
ails on here: https://github.com/dominictarr/event-stream/issues/116 P.S - this applies to anyone who uses packages that use `flatmap-stream`, not just OnsenUI. To find out if you're affected, run `npm audit`.
2 points · Open discussion
Below is the scariest part in this story: "@dominictarr Why was @right9ctrl given access to this repo?" Response: "he emailed me and said he wanted to maintain the module, so I gave it to him. I don't get any thing from maintaining this module, and I don't even use it anymore, and havn't for years. note: I no longer have publish rights to this module on npm." https://github.com/dominictarr/event-stream/issues/116#issue...
In Statement on NPM Package Vulnerability in v5.0.2-5.1.0 of Copay Bitcoin Wallets
The community discussion is focused on the wrong thing. Here is the problem: https://github.com/dominictarr/event-stream Look at that URL. It has "dominictarr" in it. Now click on the URL. Look at the big "dominictarr/event-stream" in the upper left of the screen. Many are going to conclude that this package belongs to dominictarr. Almost everything in the UI indicates this. Developers don't trust code, they trust people and organizations. NPM and Github needs to make it very clear when ownership has changed. And needs defaults that properly inform all users when ownership has changed. For example, when I SSH into a server the first time, it asks if I trust the key. Then one day, what if it asks again? Then I can stop and investigate why the key has changed, what's going on, and if I should trust it again. With the current NPM/Git
Read the rest
hub there's no warning to users. A developer could've checked dominictarr's background and decide they are trustworthy, which would then extend to event-stream as well. But where's the warning to users when ownership of event-stream has changed and they need to re-evaluate whether to trust the new owner? And why does it look like the project still belongs to dominictarr when it actually doesn't? Those are the key issues here.
In If it's not fun anymore, you get nothing from maintaining a popular package
Anyone know how this was found and whether that process can be automated? There are likely a lot more packages that are infected with the same technique. I looked at the linked commits: https://github.com/dominictarr/event-stream/commits/master and it looks so surprisingly normal. I am pretty sure I wouldn't have caught it even if I was code reviewing it. Did someone heroically rerun every package's build process to see if the minified output was tampered with?
In Backdoor in event-stream library dependency

Showing the 15 most recent of 16 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.