hunterloftis / awaiting

The async/await utility for browsers and Node.js.

Notes

I'm a mediocre developer hacking away at hard problems. Whenever I figure something out, I write a note to myself so when I inevitably have the same problem in the future, I'll have a reference.

I've been doing this for years, locally, but just recently started pushing notes to a repo.

awaiting's Issues

[Feature Request] Add a retry operation?

Any chance of a retry operation being added? Possibly with a similar feature set to that in the async library this one is partly inspired by :)

release in CDN?

Does any CDN contains this library?

can't build at create-react-app boilerplate

version

• awaiting v3.0.0
• create-react-app v1.0.5

yarn run start can work fine
yarn run build will get a error

static/js/main.ab319118.js from UglifyJs
Unexpected token operator «*», expected punc «(» [./~/awaiting/dist/awaiting.common.js:80,0][static/js/main.ab319118.js:9708,47]

Does this has plan to await http module or another node module ?

RT.

Missing LICENSE file

Hello, could you please add a LICENSE file to this project? While IANAL, I think the license field in package.json is not enough from the legal point of view.

You can use e.g. the template provided by GitHub.

feature request: auto curry

For some methods (e.g. callback) auto-currying feels like a nice extension to the existing behaviour.

e.g. const readFile = a.callback(fs.readFile)

I'm happy to work on a PR if the idea gets a 👍

Expose as ES6 Module and as separate files

... and use unpkg.com for browsers. Most simple thing can be to use Rollup to provide ES6, CJS and UMD bundle.

Mostly, the changes need to be done is:

1. add pkg.module pointing to dist/awaiting.es.js
2. add pkg.main pointing to dist/awaiting.common.js
3. add dist/ (with the slash!) to files field in package.json
4. DON'T add browser field, because Webpack(2) will use it instead of the pkg.module and pkg.main
5. browser users will use that link https://unpkg.com/awaiting/dist/awaiting.umd.js

• add note in the readme that users SHOULD NOT use the https://unpkg.com/awaiting[@version] shortcut, because it will point to commonjs build

6. create lib/index.js file that just exposes the other files
7. not sure how Documentation.JS will handle this
8. Note that it's not required to convert the source to import/export (we'll use plugin for this)

To accomplish this use can use that rollup config

const gzip = require('rollup-plugin-gzip')
const uglify = require('rollup-plugin-uglify')
const resolve = require('rollup-plugin-node-resolve')
const commonjs = require('rollup-plugin-commonjs')

let config = {
  entry: 'lib/index.js'
}

// generate minified and gzipped browser bundle 
if (process.env.BROWSER) {
  config = Object.assign(config, {
    dest: 'dist/awaiting.umd.js',
    format: 'umd',
    moduleName: 'awaiting',
    sourceMap: true,
    plugins: [
      resolve(),
      commonjs(),
      uglify({ compress: { warnings: false } }),
      gzip()
    ]
  })
} else {
  // generate CJS and ES6 non-minified and non-gzipped bundles
  config = Object.assign(config, {
    plugins: [
      resolve(),
      commonjs()
    ],
    targets: [
      { dest: 'dist/awaiting.common.js', format: 'cjs' },
      { dest: 'dist/awaiting.es.js', format: 'es' }
    ]
  })
}

and script for package.json (include npm-run-all dep)

{
  "scripts": {
    "build": "npm-run-all -s build:*",
    "build:node": "rollup -c --environment NODE",
    "build:browser": "rollup -c --environment BROWSER"
  }
}

this will generate

• dist/awaiting.es.js which should be in pkg.module
• dist/awaiting.umd.js which should NOT BE pointed in package.json
• dist/awaiting.common.js which should be in pkg.main

---

As about the tests: 1) will just use the lib/index.js since it is just commonjs, 2) no need to run them in browser so we can remove browserify, it's just enough to ensure which versions of browser support ES6.

---

I can send a PR soon. :) Great job anyway! PromiseFun can be another inspiration :)

FYI: type definitions submitted to flow-typed

Hi! I'm the one who made a comment on Reddit about submitting type definitions. The pull request is in: flow-typed/flow-typed#774

You mentioned that you might want to incorporate type annotations in the source code. The definitions here could be pulled into your own code if you want to do that. I actually prefer to ship type definitions with the library itself when writing my own libraries, and I have a Makefile that I use in most of my projects for that purpose. The way that works is that you put type annotations in your source code in src/whatever.js, the build process uses Babel to strip out annotations when building lib/whatever.js, and the build process also puts a copy of the original source with annotations preserved in lib/whatever.js.flow. Flow will automatically look for type definitions for any *.js file in a file called *.js.flow.

There are advantages to shipping types yourself, and to publishing types through flow-typed. The main advantage of flow-typed is that it can publish variations of your types for multiple versions of Flow. That can be useful for consumers who are stuck on an older version of Flow. On the other hand if types are bundled in your library you can incorporate type-checking into your tests, you can be assured that type definitions stay in sync with library releases, and you have control over publication. (The last PR that I submitted to flow-typed has been waiting to be merged for about a month.)

rat race

Any interest in adding this into your library. It's like race, but ignores errors unless all promises error
https://github.com/Financial-Times/promise-rat-race