es-shims / promise.allsettled Goto Github PK

Using 1.0.1 works but 1.0.2 breaks webpack build with:

Creating an optimized production build...
Failed to compile.

./node_modules/is-map/index.js
SyntaxError: /usr/app/node_modules/is-map/index.js: 'return' outside of function (12:1)

  10 | \t\treturn false;
  11 | \t};
> 12 | \treturn;
     | \t^
  13 | }
  14 | 
  15 | var $mapHas = $Map ? Map.prototype.has : null;

The dependency es-abstract was updated from 1.17.0-next.1 to 1.17.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

es-abstract is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

Ref tc39/proposal-promise-allSettled#41

This shim needs a fix one way or another after the outcome of the issue ref'ed above.

For the current specs it needs to at least reject the returned promise.

Example:

https://gist.github.com/leobalter/d5ddfd403c0b92333201ea7f8872d5a4#file-using-shim-js

Just was peeking at the implementation, and ran across a try..catch that was curious to me:

https://github.com/es-shims/Promise.allSettled/blob/master/implementation.js#L30-L34

Wondering if you could explain in what scenario the itemPromise.then(..) call could synchronously throw, since you're passing two known-valid functions (that you created) to it?

Hi, I have the following code inside a function that returns a promise:

throw new Error("couldn't resolve submission");

And then a I have as well:

const results = await promiseAllSettled(externalResponsePromises);

But whein I log the results const I got:

[{"status":"rejected","reason":{}}]

Why I'm not seeing the error described in the reason object?

The dependency iterate-value was updated from 1.0.0 to 1.0.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

iterate-value is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

So, I assumed that the "Typical Usage" example was supposed to be comprehensive, and that not all lines of it are required to use the function allSettled(). From that example, I did this:

    var pas = require('promise.allsettled');
    pas.shim();

    Promise.allSettled(listeners).then(()=> {
      res.status(200).send(JSON.stringify(this.putResults));
    }).catch( err => {
      wslog.warn(`POST request for ${this.filename} failed, at least in part: ${err}`)
      res.status(200).send(JSON.stringify(this.putResults));
    });

But I'm still getting TypeError: Promise.allSettled is not a function. Do I need to use all those lines just to patch Promise? Seems overkill... I only added promise.allsettled from NPM.

I'm hitting trouble when trying to use this library in a TypeScript & Babel project. I installed both the lib and the types as usual:

npm i promise.allsettled @types/promise.allsettled

The standard require (as described in README) is not TypeScript-friendly, which is normal:

const allSettled = require('promise.allsettled');

// allSettled is `any` at this point, @types are unused

That's why the type tests use this syntax:

import allSettled = require("promise.allsettled");

However, that's not supported by Babel 7 and transitively by all tools that depend on it. For example, our Jest tests fail with this:

SyntaxError: demo.ts: import = is not supported by @babel/plugin-transform-typescript
Please consider using import <moduleName> from '<moduleName>'; alongside Typescript's --allowSyntheticDefaultImports option.

Again, this is quite normal and the common fix is to create this tsconfig.json:

{
  "compilerOptions": {
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
  }
}

and use this import syntax:

import allSettled from 'promise.allsettled';

We use this for several other modules and even with promise.allsettled, TypeScript is happy at this point and Jest test pass (the promise.allsettled code is executed correctly at runtime!).

However, it leads to this error when running the app through plain node (or via ts-node):

TypeError: #<Object> is not a constructor
    at Object.resolve (<anonymous>)
    at Object.PromiseResolve (/example/node_modules/promise.allsettled/node_modules/es-abstract/es2018.js:160:10)
    at /example/node_modules/promise.allsettled/implementation.js:26:24
    at Function.from (<anonymous>)
    at Object.allSettled (/example/node_modules/promise.allsettled/implementation.js:19:22)
    at Object.allSettled [as default] (/example/node_modules/promise.allsettled/index.js:16:9)
    at myFunction (/example/demo.ts:329:53)
    at process._tickCallback (internal/process/next_tick.js:68:7)

My theory is this: in the --esModuleInterop & allowSyntheticDefaultImports mode, TypeScript transpiles the import to this:

"use strict";
var __importDefault = (this && this.__importDefault) || function (mod) {
    return (mod && mod.__esModule) ? mod : { "default": mod };
};
Object.defineProperty(exports, "__esModule", { value: true });
const promise_allsettled_1 = __importDefault(require("promise.allsettled"));

Note how it wrapped the module into default property, so the usages look like this in the transpiled code:

await promise_allsettled_1.default(...)

And probably, promise.allsettled doesn't like this and throws the #<Object> is not a constructor error.

I didn't dive deep into how the various "binds" in this library work but if there was a way to make it more friendly to that specific TypeScript emit scenario, that would be great.

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet.
We recommend using:

• CircleCI
• Travis CI
• Buildkite
• CodeShip
• Azure Pipelines
• TeamCity
• Buddy
• AppVeyor
  But Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.