bigtestjs/convergence

All BigTest development has moved to https://github.com/thefrontside/bigtest

convergence's Issues

Configure ES modules correctly

It is common in a webpack environment when using babel to not transform modules within the node_modules directory. Our package's "module" field points directly to the src files, which are typically compiled with @babel/preset-env. When babel is configured to not compile our packages within node_modules, bundles that use our packages can end up broken.

This can be seen in @bigtest/interaction tests by removing the (!?/@bigtest) regexp within the babel-loader exclude option in the karma.config.js file. This causes the package to fail to properly extend the convergence class and thereby causes every test to fail.

(moved from thefrontside/bigtest#55)

Change "stack" terminology to "queue"

It appears that Convergence#_stack is being used in a FIFO manner, but it's my understanding that a stack is FILO. This conflict is causing me to be confused. Is one of these assumptions incorrect? If not, would "queue" be more accurate?

Mocking Date breaks convergences

Problem

The main convergeOn function uses Date.now to determine if the timeout has been exceeded. When Date is mocked, and specifically when it is mocked to pause time, the convergeOn function hangs forever on failure or when using always.

Potential Solution

Instead of referencing Date globally, we should create a local root reference that can be captured before any mocks are initialized.

when() and always() are throwing "Error: convergent assertion encountered a async function or promise; since convergent assertions can run multiple times, you should avoid introducing side-effects inside of them"

bigtest/convergence v 1.1.1

it('why does it say async function when there is no async function?!', always( () => {
   expect(0).to.not.equal(1);
}));

it('why does it say async function when there is no async function?!', always( () => {
   return 0 !== 1;
}));

Questions about the `Convergence#do` API

In writing type declarations I noticed that the signature of the #do callback is:

type SideEffect<T, U> = (previous: U) => T;

This struck me as odd because I don't like mixing return values and side-effects, and it is my understanding that Convergence#do is primarily about side-effects. In its current incarnation #do does the following:

• Performs side-effects
• Maps the previous inner value to a new inner value if provided
• Flat maps the previous inner value to a new inner value if provided a Convergence or Promise instance

Basically, I guess I am wondering if it would make sense to restrict #do to side-effects only and create two new methods: #map and #flatMap, which take care of the other two bullet points respectively.

The signatures would go from this:

declare class Convergence<T> {
  // ...
  do<U>(callback: (previous: T) => U): Convergence<U>;
}

To this:

declare class Convergence<T> {
  // ...
  do(callback: (previous: T) => void): Convergence<T>;
  map<U>(callback: (previous: T) => U): Convergence<U>;
  flatMap<U>(callback: (previous: T) => Convergence<U> | Promise<U>): Convergence<U>;
}

Of note is the fact that this change would make it possible to have higher-order convergences (increasing the API surface area a bit), the implications of which I have not thought through yet and I don't know if that would be good or bad.

Just wanted to kick off this discussion and see if what I'm thinking makes sense or if I'm off base.

Remove `once` from Convergence

With thefrontside/bigtest#84 being done we should make sure we remove once & its deprecation for v1.0.0. But not before v1.0.0