benjamingr

benjamingr

Member Since 10 years ago

@Microsoft, Israel

Experience Points
802
follower
Lessons Completed
29
follow
Lessons Completed
344
stars
Best Reply Awards
190
repos

517 contributions in the last year

Pinned
⚡ Node.js JavaScript runtime :sparkles::turtle::rocket::sparkles:
⚡ :bird: :zap: Bluebird is a full featured promise library with unmatched performance.
⚡ A reactive programming library for JavaScript
⚡ Demonstrates Chrome/Firefox/Safari download 1GB favicons
⚡ Proposal for investigating RegExp escaping for the ECMAScript standard
⚡ 🔍 Root Cause is a tool for troubleshooting Puppeteer and Playwright tests. 🔎
Activity
Jan
24
18 hours ago
Activity icon
issue

benjamingr issue comment facebook/jest

benjamingr
benjamingr

fix(docs) clarify expect.any

expect.any claims that it will check an object is created with a given constructor. This doesn't match the example following it since numbers are not created using the number constructor (they may be obtained with the number constructor called as a function).

Summary

Clarify the documentation for expect.any to explain the behavior for primitives is different from the one for objects.

Activity icon
issue

benjamingr issue comment facebook/jest

benjamingr
benjamingr

fix(docs) clarify expect.any

expect.any claims that it will check an object is created with a given constructor. This doesn't match the example following it since numbers are not created using the number constructor (they may be obtained with the number constructor called as a function).

Summary

Clarify the documentation for expect.any to explain the behavior for primitives is different from the one for objects.

benjamingr
benjamingr

thanks! Could you also update the versioned docs?

Sure, let me update and push

push

benjamingr push benjamingr/jest

benjamingr
benjamingr

Update docs/ExpectAPI.md

Co-authored-by: Simen Bekkhus [email protected]

commit sha: 050d1f1529cbde5269009a05e6e72e4192a8b819

push time in 33 minutes ago
pull request

benjamingr pull request nodejs/node

benjamingr
benjamingr

stream: add asIndexedPairs

Adds the next (and second to last since we already have .from!) iterator helper from iterator helpers (ref: https://github.com/tc39/proposal-iterator-helpers#asindexedpairs )

I am not basing this on reduce and I'll just deal with merge conflicts. I took Antoine's advice and wrote the tests in .mjs and it is indeed a lot neater although admittedly this is one of the simpler ones.

After this one (and .find which I want to think a bit more about since we may want to support concurrency I want to focus on gathering feedback and iterating on the docs and on the tests (we still need a lot more coverage).

cc @aduh95 @ronag @mcollina @Mesteery @vweevers @VoltrexMaster @nodejs/streams

Activity icon
created branch

benjamingr in benjamingr/io.js create branch add-stream-asIndexedPairs

createdAt 38 minutes ago
Activity icon
issue

benjamingr issue comment nodejs/node

benjamingr
benjamingr

stream: add reduce

This continues the work in https://github.com/nodejs/node/pull/41630 so that one has to land before this one and only look at the last commit :) (same as last time, I want feedback :))

I have a few questions here about what the behaviour should be and I think my implementation may be simplified (I changed it as I added tests).

cc @ronag @mcollina @aduh95 @vweevers

benjamingr
benjamingr
Activity icon
issue

benjamingr issue comment nodejs/node

benjamingr
benjamingr

I think since this has breakage potential probably good to ping the TSC on this too @nodejs/tsc

Activity icon
issue

benjamingr issue nodejs/node

benjamingr
benjamingr

Writing tests in ESM?

Note: if you are reading this issue and not a node project member - it's about authoring tests for node about how node runs its own unit tests. It is of course possible to write tests using ES modules in node.


Hey, during a discussion with @aduh95 the idea of writing tests in ESM came up - this would be very useful since a lot of the tests I write use async/await and it'd save me to wrap everything in an IIFE + common.mustCall().

Is authoring tests (in test/parallel ) allowed in ESM?

cc @nodejs/modules @nodejs/testing

Activity icon
issue

benjamingr issue comment nodejs/node

benjamingr
benjamingr

Writing tests in ESM?

Note: if you are reading this issue and not a node project member - it's about authoring tests for node about how node runs its own unit tests. It is of course possible to write tests using ES modules in node.


Hey, during a discussion with @aduh95 the idea of writing tests in ESM came up - this would be very useful since a lot of the tests I write use async/await and it'd save me to wrap everything in an IIFE + common.mustCall().

Is authoring tests (in test/parallel ) allowed in ESM?

cc @nodejs/modules @nodejs/testing

benjamingr
benjamingr

@GeoffreyBooth because I saw only .mjs in esm related tests and I wanted to check there is no tooling related to tests that makes it problematic.

I think I'm going to assume it's allowed/fine given what @targos and you said, maybe open a docs PR to adding tests and port test files I authored to mjs since it'd save me quite a bit of boilerplate :)

Thanks!

Activity icon
issue

benjamingr issue comment nodejs/node

benjamingr
benjamingr

fs: make promises/write and writeSync params optional

Closes #41666

WIP, untested&uncovered, potentially breaking changes.

An attempt to implement "named parameters" for filehandle.write (Promises API) and fs.writeSync (Synchronous API).

  1. Segregated ArrayBufferView and string forms in documentation. Current documentation, also including fs.write (Callback API), described behaviour for string|Object argument in [buffer, offset, length, position] version.
  2. Removed Objects with own .toString functions from accepted parameters. This functionality doesn't help with most cases, when an object inherits .toString from its prototype This functionality doesn't work with Symbol.toPrimitive This functionality is easily replaceable with obj.toString(), String(obj) or ""+obj This functionality in Promises and Synchronous APIs seems to be broken for a long time
  3. Function signatures are chosen to match their .read counterparts. Promises API: buffer, offset, length, position => options Synchronous API: buffer, offset, length, position => buffer, options

Any feedback is appreciated.

Activity icon
issue

benjamingr issue comment facebook/jest

benjamingr
benjamingr

fix(docs) clarify expect.any

expect.any claims that it will check an object is created with a given constructor. This doesn't match the example following it since numbers are not created using the number constructor (they may be obtained with the number constructor called as a function).

Summary

Clarify the documentation for expect.any to explain the behavior for primitives is different from the one for objects.

benjamingr
benjamingr

cc @SimenB "First-time contributors need a maintainer to approve running workflows" since we know each other as fake-timers maintainers

pull request

benjamingr pull request facebook/jest

benjamingr
benjamingr

fix(docs) clarify expect.any

expect.any claims that it will check an object is created with a given constructor. This doesn't match the example following it since numbers are not created using the number constructor (they may be obtained with the number constructor called as a function).

Summary

Clarify the documentation for expect.any to explain the behavior for primitives is different from the one for objects.

push

benjamingr push benjamingr/jest

benjamingr
benjamingr

fix(docs) clarify expect.any

expect.any claims that it will check an object is created with a given constructor. This doesn't match the example following it since numbers are not created using the number constructor (they may be obtained with the number constructor called as a function).

commit sha: 76074cef7d0dbad94e9c2ceedf58f2d9ad6ffbc0

push time in 4 hours ago
Activity icon
fork

benjamingr forked facebook/jest

⚡ Delightful JavaScript Testing.
benjamingr MIT License Updated
fork time in 4 hours ago
open pull request

benjamingr wants to merge nodejs/node

benjamingr
benjamingr

test: add stream map tests

Adds more tests to cover more cases of map namely that it works on infinite streams and the error handling behavior. Most other methods also need these sort of tests.

cc @nodejs/streams @aduh95

benjamingr
benjamingr

Ack I'll move all of these to mjs and simplify them as soon as the two PRs by outside contributors land to not create conflicts for them.

pull request

benjamingr merge to nodejs/node

benjamingr
benjamingr

test: add stream map tests

Adds more tests to cover more cases of map namely that it works on infinite streams and the error handling behavior. Most other methods also need these sort of tests.

cc @nodejs/streams @aduh95

push

benjamingr push benjamingr/io.js

benjamingr
benjamingr

readline: undo previous edit when get key code 0x1F

  1. Undo previous edit on keystroke ctrl - (emit 0x1F)
  2. unittests
  3. documentation

PR-URL: https://github.com/nodejs/node/pull/41392 Fixes: https://github.com/nodejs/node/issues/41308 Reviewed-By: James M Snell [email protected] Reviewed-By: Qingyu Deng [email protected] Reviewed-By: Antoine du Hamel [email protected]

benjamingr
benjamingr

doc: add missing word in cluster.workers details

PR-URL: https://github.com/nodejs/node/pull/41624 Reviewed-By: Rich Trott [email protected] Reviewed-By: Colin Ihrig [email protected] Reviewed-By: Luigi Pinca [email protected] Reviewed-By: Antoine du Hamel [email protected]

benjamingr
benjamingr

tools: increase maximum line length to 120 characters

PR-URL: https://github.com/nodejs/node/pull/41586 Reviewed-By: Michaël Zasso [email protected] Reviewed-By: Mestery [email protected] Reviewed-By: Matteo Collina [email protected] Reviewed-By: James M Snell [email protected] Reviewed-By: Beth Griggs [email protected] Reviewed-By: Tierney Cyren [email protected]

benjamingr
benjamingr

doc: demonstrate dangers of buffer.slice()

PR-URL: https://github.com/nodejs/node/pull/41628 Reviewed-By: Benjamin Gruenbaum [email protected] Reviewed-By: Antoine du Hamel [email protected] Reviewed-By: Evan Lucas [email protected] Reviewed-By: Mohammed Keyvanzadeh [email protected] Reviewed-By: Mestery [email protected] Reviewed-By: Rich Trott [email protected]

benjamingr
benjamingr

build: enable zoslib installation on z/OS

zoslib is a C/C++ runtime library and an extended implementation of the z/OS LE C Runtime Library.

PR-URL: https://github.com/nodejs/node/pull/41493 Reviewed-By: Richard Lau [email protected] Reviewed-By: Michael Dawson [email protected] Reviewed-By: James M Snell [email protected] Co-authored-by: Gaby Baghdadi [email protected]

benjamingr
benjamingr

lib: remove erroneous JSDoc entry

The entry contains incorrect parameters and duplicates the subsequent constructor entry. Remove it.

(I'm not sure why this is being caught by the linter on my local machine but not in CI.)

PR-URL: https://github.com/nodejs/node/pull/41604 Reviewed-By: Mestery [email protected] Reviewed-By: Mohammed Keyvanzadeh [email protected]

benjamingr
benjamingr

doc: deprecate buffer.slice

PR-URL: https://github.com/nodejs/node/pull/41596 Reviewed-By: James M Snell [email protected] Reviewed-By: Matteo Collina [email protected] Reviewed-By: Anna Henningsen [email protected] Reviewed-By: Antoine du Hamel [email protected]

benjamingr
benjamingr

benchmark: add subarray to buffer-slice

PR-URL: https://github.com/nodejs/node/pull/41596 Reviewed-By: James M Snell [email protected] Reviewed-By: Matteo Collina [email protected] Reviewed-By: Anna Henningsen [email protected] Reviewed-By: Antoine du Hamel [email protected]

benjamingr
benjamingr

buffer: alias subarray and slice

PR-URL: https://github.com/nodejs/node/pull/41596 Reviewed-By: James M Snell [email protected] Reviewed-By: Matteo Collina [email protected] Reviewed-By: Anna Henningsen [email protected] Reviewed-By: Antoine du Hamel [email protected]

benjamingr
benjamingr

test: fix typo in test-stream-toArray

Refs: https://github.com/nodejs/node/pull/41553

PR-URL: https://github.com/nodejs/node/pull/41634 Reviewed-By: Richard Lau [email protected] Reviewed-By: Benjamin Gruenbaum [email protected] Reviewed-By: Mestery [email protected] Reviewed-By: Rich Trott [email protected]

benjamingr
benjamingr

process: use validateString validator

Use the validateString() validator where applicable.

PR-URL: https://github.com/nodejs/node/pull/41595 Reviewed-By: Colin Ihrig [email protected] Reviewed-By: Michaël Zasso [email protected] Reviewed-By: Benjamin Gruenbaum [email protected] Reviewed-By: Antoine du Hamel [email protected] Reviewed-By: Mestery [email protected] Reviewed-By: Luigi Pinca [email protected]

benjamingr
benjamingr

doc: add note for handling signal events in trace events

Refs: https://github.com/nodejs/node/issues/14802

PR-URL: https://github.com/nodejs/node/pull/41438 Reviewed-By: James M Snell [email protected] Reviewed-By: Adrian Estrada [email protected] Reviewed-By: Mary Marchini [email protected] Reviewed-By: Gerhard Stöbich [email protected] Reviewed-By: Santiago Gimeno [email protected]

benjamingr
benjamingr

lib: fix consistency of methods that emit warnings

PR-URL: https://github.com/nodejs/node/pull/41249 Reviewed-By: Daijiro Wachi [email protected] Reviewed-By: James M Snell [email protected] Reviewed-By: Mestery [email protected]

benjamingr
benjamingr

doc: improve 'hex' Buffer decoding description and examples

PR-URL: https://github.com/nodejs/node/pull/41598 Fixes: https://github.com/nodejs/node/issues/41594 Reviewed-By: Benjamin Gruenbaum [email protected] Reviewed-By: Antoine du Hamel [email protected] Reviewed-By: Tobias Nießen [email protected] Reviewed-By: Anna Henningsen [email protected] Reviewed-By: Mestery [email protected] Reviewed-By: Luigi Pinca [email protected] Reviewed-By: Rich Trott [email protected]

benjamingr
benjamingr

readline: add feature yank and yank pop

  1. Ctrl-Y to yank previously deleted text
  2. Meta-Y to do yank pop (cycle among deleted texts)
  3. Use getCursorPos().rows to check if we have reached a new line, instead of getCursorPos().cols === 0.
  4. document and unittests.

PR-URL: https://github.com/nodejs/node/pull/41301 Fixes: https://github.com/nodejs/node/issues/41252 Reviewed-By: James M Snell [email protected] Reviewed-By: Qingyu Deng [email protected]

benjamingr
benjamingr

crypto: adjust types for getRandomValues

prevents Web Crypto API's getRandomValues from accepting DataView

Fixes: https://github.com/nodejs/node/issues/41480 Refs: https://www.w3.org/TR/WebCryptoAPI/#Crypto-method-getRandomValues

PR-URL: https://github.com/nodejs/node/pull/41481 Reviewed-By: Derek Lewis [email protected] Reviewed-By: Luigi Pinca [email protected] Reviewed-By: Zeyu Yang [email protected] Reviewed-By: Tobias Nießen [email protected] Reviewed-By: James M Snell [email protected]

benjamingr
benjamingr

crypto: remove wildcard options for checkEmail

Wildcard options do not affect X509_check_email.

Refs: https://github.com/openssl/openssl/pull/17536 Refs: https://github.com/nodejs/node/pull/41571

PR-URL: https://github.com/nodejs/node/pull/41599 Reviewed-By: Tierney Cyren [email protected] Reviewed-By: Filip Skokan [email protected]

benjamingr
benjamingr

crypto: change default check(Host|Email) behavior

This changes the default behavior of the X509Certificate functions checkHost and checkEmail to match the default behavior of OpenSSL's X509_check_host and X509_check_email functions, respectively, which is also what RFC 2818 mandates for HTTPS.

Refs: https://github.com/nodejs/node/pull/36804 Refs: https://github.com/nodejs/node/pull/41569

PR-URL: https://github.com/nodejs/node/pull/41600 Reviewed-By: Matteo Collina [email protected] Reviewed-By: Rich Trott [email protected] Reviewed-By: Filip Skokan [email protected]

benjamingr
benjamingr

doc: add 16 and 17 to previous versions

PR-URL: https://github.com/nodejs/node/pull/41646 Reviewed-By: Michaël Zasso [email protected] Reviewed-By: Tobias Nießen [email protected] Reviewed-By: Mohammed Keyvanzadeh [email protected] Reviewed-By: Mestery [email protected] Reviewed-By: Rich Trott [email protected]

benjamingr
benjamingr

test: move test-gc-http-client-onerror to sequential

Fixes: https://github.com/nodejs/node/issues/41399

PR-URL: https://github.com/nodejs/node/pull/41619 Reviewed-By: Rich Trott [email protected] Reviewed-By: Colin Ihrig [email protected] Reviewed-By: Santiago Gimeno [email protected]

commit sha: a5d10870149e5dc8f5772510d98b39f06d91bb58

push time in 5 hours ago
Activity icon
issue

benjamingr issue comment nodejs/node

benjamingr
benjamingr

test: add stream map tests

Adds more tests to cover more cases of map namely that it works on infinite streams and the error handling behavior. Most other methods also need these sort of tests.

cc @nodejs/streams @aduh95

benjamingr
benjamingr

I'm giving you Co-Authored-By on the commit @aduh95 for the feedback and help. If you prefer otherwise let me know.

Activity icon
issue

benjamingr issue comment nodejs/node

benjamingr
benjamingr

test: add stream map tests

Adds more tests to cover more cases of map namely that it works on infinite streams and the error handling behavior. Most other methods also need these sort of tests.

cc @nodejs/streams @aduh95

benjamingr
benjamingr

Ah phew that's much much better and a way less severe bug. I'll push a fix.

Activity icon
issue

benjamingr issue comment nodejs/node

benjamingr
benjamingr

test: add stream map tests

Adds more tests to cover more cases of map namely that it works on infinite streams and the error handling behavior. Most other methods also need these sort of tests.

cc @nodejs/streams @aduh95

benjamingr
benjamingr

@aduh95

setImmediate is scheduled after 100ms? Would replacing setImmediate with queueMicrotask save us here? Or use a very big number for the setTimeout value?

The failing test doesn't seem to use timers at all -

{
  // Map works on non-objectMode streams
  const stream = new Readable({
    read() {
      this.push(Uint8Array.from([1]));
      this.push(Uint8Array.from([2]));
      this.push(null);
    }
  }).map(async ([x]) => {
    return x + x;
  }).map((x) => x + x);
  const result = [4, 8];
  (async () => {
    for await (const item of stream) {
      assert.strictEqual(item, result.shift());
    }
  })().then(common.mustCall());
}

That's the one that's flakey on arm if I understand correctly right?

open pull request

benjamingr wants to merge nodejs/node

benjamingr
benjamingr

test: add stream map tests

Adds more tests to cover more cases of map namely that it works on infinite streams and the error handling behavior. Most other methods also need these sort of tests.

cc @nodejs/streams @aduh95

benjamingr
benjamingr

wouldn't you agree this would be a semver-major change?

Not on an experimental API - once it graduates 100% absolutely.

The proposal says we should Await at each step, so I would think that implies the same rejected object is returned.

Yes but note that in this case the user is explicitly emiting the error event rather than throwing an error - I agree that for throwing we 100% should align.


Non-blocking suggestion.

Please keep making suggestions discussing these things is important!

pull request

benjamingr merge to nodejs/node

benjamingr
benjamingr

test: add stream map tests

Adds more tests to cover more cases of map namely that it works on infinite streams and the error handling behavior. Most other methods also need these sort of tests.

cc @nodejs/streams @aduh95

Activity icon
issue

benjamingr issue comment nodejs/node

benjamingr
benjamingr

test: add stream map tests

Adds more tests to cover more cases of map namely that it works on infinite streams and the error handling behavior. Most other methods also need these sort of tests.

cc @nodejs/streams @aduh95

benjamingr
benjamingr

@aduh95 hmm, any idea why it's failing?

cc @ronag

open pull request

benjamingr wants to merge nodejs/node

benjamingr
benjamingr

test: add stream map tests

Adds more tests to cover more cases of map namely that it works on infinite streams and the error handling behavior. Most other methods also need these sort of tests.

cc @nodejs/streams @aduh95

benjamingr
benjamingr

I'm not sure that's actually a guarantee we necessarily want to make in this case (that is - that if we emit we don't wrap the error in any way) - the guarantee currently tested is much smaller (that we include the message).

If you feel strongly it's a guarantee we should make - I'll change it (we should also probably update the docs)

pull request

benjamingr merge to nodejs/node

benjamingr
benjamingr

test: add stream map tests

Adds more tests to cover more cases of map namely that it works on infinite streams and the error handling behavior. Most other methods also need these sort of tests.

cc @nodejs/streams @aduh95

pull request

benjamingr merge to nodejs/node

benjamingr
benjamingr

tools: use Set instead of `{ [key]: true }` object

A Set has clearer semantics than an object whose values are always true.

Activity icon
issue

benjamingr issue comment tc39/proposal-observable

benjamingr
benjamingr

Simplification of Observable API

Okay, I'm going to throw my hat back in and see if I can resurrect this a little.

What I'm going to propose is slightly different than the current proposal and different than RxJS, but I strongly feel it will work.

API

interface Observable<T> {
  new (
    initialization: (
      nextHandler: (value: T) => void,
      errorHandler: (err: any) => void,
      completeHandler: () => void, 
      signal: AbortSignal
     ) => void;
  ): Observable<T>

  subscribe(
      nextHandler?: (value: T) => void,
      errorHandler?: (err: any) => void,
      completeHandler?: () => void, 
      signal?: AbortSignal
  ): void;

  forEach(nextHandler: (value: T) => void, signal: AbortSignal): Promise<void>

  first(signal: AbortSignal): Promise<T>;

  last(signal: AbortSignal): Promise<T>;
}

The idea is to remove the need to define Observer and Subscriber, as in other Observable implementations, and use simple functions instead. Also using a cancellation token (ala AbortController/AbortSignal) instead of introducing a Subscription type.

I realize that AbortController and AbortSignal are not a part of JavaScript proper. However, I strongly feel JavaScript could use a cancellation primitive, and Observable, which is also a primitive, is not as useful without it.

Defining an observable instance

Below is the simplest use case for an observable. A synchronous set of values.

  test("should at least work", () => {
    const source = new Observable((next, error, complete, signal) => {
      next(1);
      next(2);
      next(3);
      complete();
    });

    let results = [];

    source.subscribe(value => results.push(value), null, () =>
      results.push("done")
    );

    expect(results).toEqual([1, 2, 3, "done"]);
  });

Handling of "firehose" synchronous data

With a cancellation token, like AbortSignal, handling synchronous firehoses and stopping them due to external unsubscription becomes a bit more intuitive than it was with previous designs, IMO:

 test("should handle firehose", () => {
    let loops = 0;
    const source = new Observable((next, err, complete, signal) => {
      for (let i = 0; i < 1000000000 && !signal.aborted; i++) {
        next(i);
        loops++;
      }
      // this will noop due to protections after abort below
      // which is "unsubscription".
      complete();
    });

    const controller = new AbortController();
    const results = [];

    source.subscribe(
      value => {
        results.push(value);
        if (results.length === 3) {
          // "unsubscribe"
          controller.abort();
        }
      },
      null,
      // complete should not be called, because of the
      // abort (unsubscription) above
      () => results.push("done"),
      controller.signal
    );

    expect(loops).toBe(3);
    expect(results).toEqual([0, 1, 2]);
  });

Concessions

first and last may not be necessary, and are more "nice to have"s for this type. Their primary use cases would be for wrapped HTTP calls, which, in a world where AbortSignals were prolific, should probably just be done via fetch.

Cons

There are a few cons to this design. Notably, from my perspective, it's not completely compatible with current popular designs. But I'm less worried about that than getting the appropriate primitives into the language.

Other thoughts

It's possible to have this implement Symbol.asyncIterator with a known behavior, like buffering all values internally until they are read. This, of course, comes with some potential issues around back-pressure and memory pressure, but I think that's easy to understand for most people who might use this type with for await.

Another con is creating a "Subject", which is a common type created to compose with observables, becomes mildly challenging, in that it would need to be something that could be destructured into three functions and an abort signal, but again, I don't think that's really a concern for language authors. The community can take care of that.

Links

I've tossed together a demo here.

Repo: https://github.com/benlesh/tc39-observable-proposal Codesandbox: https://codesandbox.io/s/tc39-observable-proposal-proposed-change-uxh4p

benjamingr
benjamingr

I don’t really know though when you would prefer one over the other in real life.

I can literally talk for 12 hours on the advantages of push streams (like observables) vs. pull streams (like async iterators) but to name a few:

  • observables guarantee they never buffer so you have a much stronger memory guarantee.

  • observables are super-strict (read: eager) which means you get data "as soon as possible" from the producer.

  • observables provide a much simpler interface since all they do is push data - the protocol is just "you subscribe to me and get updates".

  • observables (mostly) have to be "functions to actions" since because they are so eager - they require the extra step from observable to observer.

  • observables give all the rate control to the producer.

  • async iterators can buffer - if I have an iterator for click events and I do not consume it - it will "buffer" the click events for me and when I iterate it I can get events "from the past".

  • async iterators are lazy, which means they can support backpressure very easily (that is, controlling how much data you ask from the producer to even-load chained iterators).

  • async iterators are a pretty complicated interface making them harder to implement. They build on promises so their timing guarantees are different though that's just a detail and not push vs. pull.

  • If you have an async iterator - you already have a thing for consuming the resources (like an observer and unlike an observable) which you can only get away with because iteration is itself lazy.

  • all the control is at the consumer side.

Note RxJS already supports Symbol.asyncIterator and since it's the most popular implementation anyway I recommend you experiment with that.

Activity icon
issue

benjamingr issue nodejs/node

benjamingr
benjamingr

Writing tests in ESM?

Note: if you are reading this issue and not a node project member - it's about authoring tests for node about how node runs its own unit tests. It is of course possible to write tests using ES modules in node.


Hey, during a discussion with @aduh95 the idea of writing tests in ESM came up - this would be very useful since a lot of the tests I write use async/await and it'd save me to wrap everything in an IIFE + common.mustCall().

Is authoring tests (in test/parallel ) allowed in ESM?

cc @nodejs/modules @nodejs/testing

Previous