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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 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

24 sources
Whole npm ecosystem is so fragile. Remember event-stream[1]? Did we learned something from that? Yes, we might. So was it improved? Never. People are still installing 'new' colors package and wondering why its texts are broken. What if he uploaded malicious code rather than just just gibberish? What if he uploaded on only npm and not on GitHub? Would we even notice that? [1]: https://github.com/dominictarr/event-stream/issues/116
In What NPM should do to stop a new colors attack
> The threat model you're talking about neither seems realistic, nor like something npm audit can help with. The attack vector of a contributor sneaking in malicious code is dealt with by only giving the commit bit to trusted people, and reviewing code yourself. How is this not realistic when it has already been seen in the npm ecosystem multiple times. For an example of this in the wild see the event-stream (crypto-mining trojan) fiasco: https://github.com/dominictarr/event-stream/issues/116 Dependencies are a target for exploit, your package may be safe now and then become unsafe in the future, either intentionally or unintentionally.
In Npm Audit: broken by design?
It's a matter of expectations. I believe expectations are extremely important when releasing anything creative, be it code or art or writing. You might release something as a side project of a hobby, but people will become angry with you if it doesn't do what's advertised. This is significantly amplified if you go out of your way to tell people the project exists, in the hopes of it becoming popular and used. It can't become popular if it isn't good enough. That's the same for many different disciplines and various subjective standards of "good." In the case of software correctness is often stressed, unless it's generative art or something. So by marketing something in the hopes of it becoming popular you obligate yourself to getting it to the point where it can become popular. So it's about not looking arrogant by saying something is tru
Read the rest
e about a project when it isn't. The problem isn't as simple as "don't mind if it's bad." Your library could end up being used in hundreds of projects. People want continued maintenance in this case. They might start filing issues against your project because of unforseen downstream bugs. But you might not feel like maintaining it anymore. Motivations change. But you'd have to be careful if you choose to hand off maintenance, because this can happen: https://github.com/dominictarr/event-stream/issues/116 So it isn't just a case of whether or not the code itself is bad. It's also about how you market the code to others. Ward people away if it's not production-ready. Sometimes undersell and never oversell. Remove any reason for people's expectations to be out of sync with the actual quality. In the case of event-stream the old maintainer became relied upon and then made the incorrect decision of letting an untrustworthy person have access to the code. And also make clear your motivations. The creator of uBlock Origin states he might get bored of the project and move on. Give yourself an escape hatch like this so you can excuse yourself if you believe you really can't find yourself with the will to keep working on it in the future. As long as those expectations are very clear to anyone who uses your code, then it is okay for public code to be bad.
In It’s OK for your open source library to be a bit shitty (2015)
I wonder if there is any research on whether someone is better off not updating at all or automatically updating. I would bet that apps are better off automatically updating to remove published vulnerabilities than they are worrying about the handful of bitcoin wallet stealing backdoors. [1] It comes down to trust. Automatically updating something like https://www.npmjs.com/package/express is probably pretty safe. Automatically updating a relatively unknown package made by an unknown person is much less safe. Also, it goes beyond application dependency changes. What about your build server or that SaaS build pipeline you use? Key infrastructure gets hacked [2][3] and it turns out all the time you spent reviewing express updates should have instead been spent reviewing changes from somewhere else. [1]: https://github.com/dominictarr/event-
Read the rest
In Automate GitHub Dependency Updates with Dependabot
This is actually a much more responsible way to go about it than the event-stream issue, since it is being done in a public forum (Github issues). Event-stream was given away over an Email without an announcement [0]. Of course, the risks are still there for malicious takeover, but I think will be minimized due to the owner's notoriety and the amount of press this has already seen just on GitHub. I am pretty sure the maintainers of Pip will be keeping an eye on this over the next few months in case of intervening. [0] https://github.com/dominictarr/event-stream/issues/116#issue...
In Issue: find a new home for repos including Requests
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

Showing the 15 most recent of 24 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.