mearns / extrinsic-promises Goto Github PK

When using node's require() function to include this package, the ExtrinsicPromise class is only available as the value of the default property.

Work around

Access the ExtrinsicPromise class through the default property of the require'd module:

const ExtrinsicPromise = require('extrinsic-promises').default

Root Cause

Babel's transpilation of export default sets the export target as module.exports.default. It transpilates import to work accordingly, but if you're not using babel's import, it doesn't work so well.

When you try to import or require the package, you get an error that "source-map-support" package is not found, preventing this package form being used.

Work Around

Install the npm package called "source-map-support" as a dependency in any project that uses the "extrinsic-promises" package.

Root cause

The dependency is listed as a dev dependency, but not a run-time dependency. It is injected into the transpiled code by the node-suource-map-support babel plugin.

Version 2.0.0 doesn't work when included in a webpack and executed in a browser because it requires the npm source-map-support package, which requires fs.

If you run npm audit from the repo, you'll get a bunch of warnings. We need someone to go through and fix these. If you're looking for a way to contribute to this package, the npm ecosystem, or open source software in general, you can fork this repo, address as many or as few of these audit issues as you want, and submit a pull request =)

Mocha tests fail in node v5, starting in version 1.3.1 with the following error:

.../extrinsic-promises/node_modules/nyc/node_modules/find-up/index.js:5
module.exports = (filename, opts = {}) => {
                                 ^
SyntaxError: Unexpected token =
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:387:25)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Module.require (module.js:367:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/home/travis/build/mearns/extrinsic-promises/node_modules/nyc/lib/config-util.js:6:16)
    at Module._compile (module.js:413:34)
    at Object.Module._extensions..js (module.js:422:10)

Version 1.1.0 added the ExtrinisicPromise::adopt() method to the source code, but when it was published, it was not included in the transpiled code, so it is not actually available in the installed package.

When you use the adopt method, and the adopted method eventually rejects, you end up with an unhandled rejection warning from Node, which in future versions will be a failure.

Work Around

No known workaround

Root Cause

The adopt() method attaches handlers to the adopted promise, but these handlers only cause the ExtrinsicPromise to be returned, forming a chain. When the ExtrinsicPromise rejects, this causes the chain starting with the adopted promise to reject as well, with no additional handlers attached.

The solution is to add additional handlers to the end of this chain which handle the rejection (by doing nothing). This is fine because the chain created in here isn't useful, it's just used for its side-effect, which is to settle the ExtrinsicPromise.

Hello there!

My name is Ana. I noted that you use the mutation testing tool StrykerJS in the project.
I am a postdoctoral researcher at the University of Seville (Spain), and my colleagues and I are studying how mutation testing tools are used in practice. With this aim in mind, we have analysed over 3,500 public GitHub repositories using mutation testing tools, including yours! This work has recently been published in a journal paper available at https://link.springer.com/content/pdf/10.1007/s10664-022-10177-8.pdf.

To complete this study, we are asking for your help to understand better how mutation testing is used in practice, please! We would be extremely grateful if you could contribute to this study by answering a brief survey of 21 simple questions (no more than 6 minutes). This is the link to the questionnaire https://forms.gle/FvXNrimWAsJYC1zB9 .

We apologize if you have already received message multiple times or if you have already had the opportunity to complete the survey. If you have already shared your feedback, we want to convey our appreciation, kindly disregard this message, and please accept our apologies for any inconvenience.

Drop me an e-mail if you have any questions or comments ([email protected]). Thank you very much in advance!!

I'm tired of maintaining babel in this project. It's on the old babel v6 and the massive dependency tree ends aways ends up with security issues. And it's really not needed for such a small project.

Acceptance Criteria

This ticket is complete when the following statements are true of this codebase:

• There are no babel related dependencies in package.json.
• There are no npm scripts defined that use babel.
• All "compile*" scripts have been removed from package.json
• The "stryker.conf.js" file no longer uses babel.
• The travis-ci file no longer contains matrix entries for NODE_ENVIRONMENT=development
• The travis-ci matrix no longer sets the NODE_ENVIRONMENT.
• The travis-ci file uses the build script instead of compile test (any entries that use just compile can be removed).

Definition of Done

Additionally, the following should all be true as a matter of course:

• All existing unit tests pass on all supported Node versions (>=6 <13).
• Mutation tests pass (npm run mutation-test finds "No surviving mutants at all.").
• No npm audit issues exist.
• package-lock.json is up to date.

You may, optionally, expand the supported node versions up through the current LTS version. If you do so, add it to the travis CI matrix, add it to the engines property in package.json, and make sure it actually works.