DEV Community: Arnaud

Authoring a JavaScript library that works everywhere using Rollup

Arnaud — Tue, 06 Oct 2020 19:15:54 +0000

In this article, we aim to create and publish a library that can be used, without any changes in the code, in both client side and server side applications.

We need to fulfill the following use cases:

The library is written in ES6+, using import and export keywords
The library can be used with a <script> tag
The library can be used in a web application that uses a modern bundler.
The library can be used in a node application.

Technically, this means the library needs to work in the following contexts:

Using a <script> tag:

<html>
  <head>
    <script src="scripts/my-library.min.js"></script>
  </head>
  <body>
    <div id="app" />
    <script>
      myLibrary.helloWorld();
    </script>
  </body>
</html>

Using RequireJS:

define(["my-library"], function (myLibrary) {});
// or
define(function (require) {
  var myLibrary = require("my-library");
});

In a web application using a bundler such as webpack:

import { helloWorld } from "my-library";
helloWorld();

In a node application:

const myLibrary = require("my-library");
myLibrary.helloWorld();
// or
const { helloWorld } = require("my-library");
helloWorld();

Note: In the web application using a bundler, there is no way to import the whole library and call individual functions on it (import lib from 'library'; lib.sayHello();), and that’s completely intentional. We want consumers to call just the bits they use so tree-shaking can do its work and dead code is eliminated when bundling the final application. Remember, in the case of an application using a modern bundler, the consuming web application will also produce a bundle for deployment, and we want that to be as small as possible, so we’ll spare our consumers from having to include code that is not used in their application.

To achieve all this, we’re going to use rollup.js. The main reasons is that Rollup is very fast (although not the fastest), requires minimal configuration, and supports everything we need through its convenient plugin system.

Once our library is written, we will use Rollup to export the code in the following three formats:

UMD (Universal Module Definition): this will support the use of a script tag, and RequireJS. As the consuming app will not be transpiling or bundling the code themselves, we need to provide a version of our library that is minified and transpiled for wide browser support.
ESM (ES2015 Module): this will allow bundlers to import our application, eliminate dead code and transpile it down to the level they choose. We’re still compiling the code, but just providing it in a format that’s convenient for consumers and letting them decide what to do next. This will allow the import keyword to work.
CJS (CommonJS): the format of choice for Node.js. No tree-shaking needed here as code size doesn’t matter as much, this format allows the use of the require keyword in a node application.

For each of these format, we will also provide a source map so consumers can debug the library should they need to.

The first step is to create a project:

$ mkdir my-library
$ cd my-library
$ npm init -y

Next we need to add some dependencies.
Obviously , we need rollup.

$ npm install rollup --save-dev

We know that we need to transpile the code for the UMD format, so let’s install babel:

$ npm install @babel/core @babel/preset-env --save-dev

We also need rollup to use babel and to minify the code, so let’s install the necessary plugins to use babel and terser:

$ npm install @rollup/plugin-babel rollup-plugin-terser --save-dev

And finally, we want to be able to use the import/export syntax in our library in the style of node: this allows us to write import fn from './fn' instead of import fn from './fn/index.js' and of course to use modules from the node_modules directory (which we are not doing here).

$ npm install @rollup/plugin-node-resolve --save-dev

The final list of dependencies of our library should look something like this:

"dependencies": {},
"devDependencies": {
  "@babel/core": "^7.11.6",
  "@babel/preset-env": "^7.11.5",
  "@rollup/plugin-babel": "^5.2.1",
  "@rollup/plugin-node-resolve": "^9.0.0",
  "rollup": "^2.28.2",
  "rollup-plugin-terser": "^7.0.2"
},

We also need a directory for our source code, a configuration file for babel, and a configuration file for rollup:

$ mkdir src
$ touch .babelrc.json
$ touch rollup.config.js

The babel configuration is going to be very simple, we just need to tell babel that we want to use the most recent version of JavaScript:

{
  "presets": [["@babel/env", { "modules": false }]]
}

For Rollup, we need to import the necessary plugins:

import { nodeResolve } from "@rollup/plugin-node-resolve";
import { terser } from "rollup-plugin-terser";
import babel from "@rollup/plugin-babel";

And we’re also going to import the package.json, so we can use the name field when exporting the UMD bundle:

import pkg from "./package.json";

Our rollup.config.js is going to do two things:

For UMD: take the code, process it and run it through babel (transpile) and terser (minify), and export it as a UMD consumable file.

{
  // UMD
  input: "src/index.js",
  plugins: [
    nodeResolve(),
    babel({
      babelHelpers: "bundled",
    }),
    terser(),
  ],
  output: {
    file: `dist/${pkg.name}.min.js`,
    format: "umd",
    name: "myLibrary",
    esModule: false,
    exports: "named",
    sourcemap: true,
  },
},

For CJS/ESM: take the code, process it, and export it as an ESM module, and as a CJS module. Remember, in this case, we don’t need to transpile or minify. Node doesn’t need it, and for ESM, the consumer will do that.

{
  input: ["src/index.js"],
  plugins: [nodeResolve()],
  output: [
    {
      dir: "dist/esm",
      format: "esm",
      exports: "named",
      sourcemap: true,
    },
    {
      dir: "dist/cjs",
      format: "cjs",
      exports: "named",
      sourcemap: true,
    },
  ],
},

In all instances however, we generate a sourcemap.

Note the exports: "named" option in all configs, there’s a longer explanation in rollup’s documentation, essentially this tells rollup that we’re using named exports over default exports. Long story short, this allows the widest possible compatibility, and makes tree shaking happen. If you use a linter, make sure to configure it to favor named exports over default exports (this doesn’t apply to applications, only to libraries, it’s completely fine to use default exports and even mix default/named exports for applications).

The complete rollup file looks like this. And because the name is taken from the package.json, you can actually use this file almost as is, as long as the entry point is src/index.js and the name is set accordingly in the output of the UMD module.

import { nodeResolve } from "@rollup/plugin-node-resolve";
import { terser } from "rollup-plugin-terser";
import babel from "@rollup/plugin-babel";
import pkg from "./package.json";
const input = ["src/index.js"];
export default [
  {
    // UMD
    input,
    plugins: [
      nodeResolve(),
      babel({
        babelHelpers: "bundled",
      }),
      terser(),
    ],
    output: {
      file: `dist/${pkg.name}.min.js`,
      format: "umd",
      name: "myLibrary", // this is the name of the global object
      esModule: false,
      exports: "named",
      sourcemap: true,
    },
  },
  // ESM and CJS
  {
    input,
    plugins: [nodeResolve()],
    output: [
      {
        dir: "dist/esm",
        format: "esm",
        exports: "named",
        sourcemap: true,
      },
      {
        dir: "dist/cjs",
        format: "cjs",
        exports: "named",
        sourcemap: true,
      },
    ],
  },
];

Now that we have our dependencies, configured babel and rollup, time to write the code.
We’re going to layout our files like so:

src
├── goodbye
│   ├── goodbye.js
│   └── index.js
├── hello
│   ├── hello.js
│   └── index.js
└── index.js

And the code is going to be extremely simple:

// src/index.js
export { default as hello } from "./hello";
export { default as goodbye } from "./goodbye";

// src/hello/index.js
export { default } from "./hello";

// src/hello/hello.js
export default function hello() {
  console.log("hello");
}

// src/goodbye/index.js
export { default } from "./goodbye";

// src/goodbye/goodbye.js
export default function goodbye() {
  console.log("goodbye");
}

Next we need to call rollup and tell it to do its job. For convenience’s sake, we’re going to create two npm scripts, one for building the library, and a dev task which will recompile the code every time a change is made:

“scripts”: {
 “build”: “rollup -c”,
 “dev”: “rollup -c -w”
},

Finally we need to describe how the application is exported, both for npmjs to make it available, and for consumers to use.

We’re going to define three values in package.json:

The files option that tells npm what to pack (this can be tested using npm pack ), the main option that point to a CJS module, and the module option, which while not standard, has become the norm for ESM modules.

// package.json
...
"main": "dist/cjs/index.js",
"module": "dist/esm/index.js",
...
files: [
  "dist"
]

And that’s it!
To build the library, just run npm run build and while developing, you can use npm run dev . The export can be tested using npm pack.

Testing the library

Using the script tag, simply create an HTML file, and open it in a browser. You will see the word “hello” printed in the console.

<html>
  <head>
    <script src="dist/my-library.min.js"></script>
  </head>
  <body>
    <script>
      myLibrary.hello();
    </script>
  </body>
</html>

Using Requires.JS, create a small webapp and serve it using serve :

www
├── index.html
└── scripts
├── app.js
├── my-library.min.js
└── require.js

index.html
<html>
  <head>
    <script data-main="scripts/app.js" src="scripts/require.js"></script>
  </head>
  <body></body>
</html>

// app.js
requirejs.config({
  baseUrl: "scripts",
});
requirejs(["my-library.min"], function (myLibrary) {
  myLibrary.hello();
});

The word ‘hello’ will be printed in the console. Once the module is published, the file my-library.min.js will be available from https://unpkg.com/.

From node, outside of the library directory, create a js file and require the module by pointing to the my-library directory (not the dist folder!):

const myLibrary = require("../my-library");
myLibrary.hello(); // hello
myLibrary.goodbye(); // goodbye

If you take it a step further and debug the application, the source map will kick in too!

From a web application using webpack, like a React application:

$ npx create-react-app my-library-cra
$ cd my-library-cra

In the dependencies section of the package.json, simply add this line:

"my-library": "../my-library/"

And run yarn install
In src/App.js, import and invoke the hello function only:

import { hello } from "my-library";
hello();

Run the React application using yarn start and open the JavaScript console, and you should see the “hello” word printed.

Now to make sure tree shaking works, run yarn build. The React application will be bundled and put into the build directory. If you do a search in files for the hello keyword, you will see that it is in a js file with a long complicated name, but the keyword goodbye cannot be found. This shows that webpack only pulled in the necessary code. And since we are using a named export in our library, consumers of our library cannot write import myLibrary from 'my-library'; and mistakenly import the entire package while only using a fraction of it.

Hope this helps, let me know if you have any questions in the comments!

You don’t need React to use JSX

Arnaud — Thu, 24 Sep 2020 14:53:45 +0000

In this article, we explain the new JSX Transform, and how to use JSX without React.

The official React blog does not get many updates, so a new post is always attention worthy, but this week’s post, Introducing the New JSX Transform, could be a much bigger deal than it seemingly appears.

In this post, Luna Ruan announces a new JSX Transform, and one of the benefits is that “you can use JSX without importing React.”.

For those who don’t know, JSX is the HTML like syntax which is used by React components to render in the browser:

import React from 'react';
function MyComponent() {
  return <div>This is JSX</div>;
}

When you use JSX, the compiler transforms it into React function calls that the browser can understand, so the above code becomes:

import React from 'react';
function MyComponent() {
  return React.createElement('div', null, 'This is JSX');
}

This is done using a babel plugin called @babel/plugin-transform-react-jsx.

Now note the import React from 'react';. That line is not inserted by the plugin, it is just copied over from the React component, and this is why React imports are needed in any file containing JSX. Even if there are no references to the React package in the original file, there are references to it in the transpiled result and that’s why React is needed.

But starting with v7.9.0, the JSX transform plugin provides a new mode, called automatic, which outputs this:

// Inserted by a compiler (don't import it yourself!)
import {jsx as _jsx} from 'react/jsx-runtime';

function MyComponent() {
  return _jsx('div', { children: 'This is JSX' });
}

So this means that we no longer need to import React in files that use JSX, as the import is inserted by the compiler, so our component can now be written like this:

function MyComponent(){
  return <div>This is JSX</div>;
}

That in itself is pretty convenient, but that’s not what blew my socks off. If we look a little deeper in the announcement, we find this note:

| If you use JSX with a library other than React, you can use the importSource option to import from that library instead

So… That’s exactly what we’re going to do!

We’re going to write a file containing JSX, and write our own runtime to convert it from JSX to HTML, right there in a node application. JSX without React and without a browser!

First we’re going to initialize our project, and we’re going to need a few dependencies. Babel and the plugin-transform-react-jsx to compile our files, esm to support import/export statements, and of course jsdom to generate HTML in node.

Notice how we are not importing React.

$ npm init -y
$ npm install @babel/cli @babel/core @babel/plugin-transform-react-jsx esm jsdom

To make sure all the versions are correct, here is my package.json

"dependencies": {
    "@babel/cli": "^7.11.6",
    "@babel/core": "^7.11.6",
    "@babel/plugin-transform-react-jsx": "^7.10.4",
    "esm": "^3.2.25",
    "jsdom": "^16.4.0"
  }

Next we need a .babelrc file which tells babel what to do.

From the blog post, we know we need to do two things: use the new automatic runtime, and use the importSource option to specify our own runtime:

// .babelrc
{
  "plugins": [
    [
      "@babel/plugin-transform-react-jsx",
      {
        "runtime": "automatic",
        "importSource": "../runtime"
      }
    ]
  ]
}

Let’s also make a few directories, one will contain our source code, one will contain the runtime we’re going to build, and one will contain the compiled source code:

$ mkdir src lib runtime

Our sample app is going to be a simple list of items:

// src/App.js
function List({ items }) {
  return (
    <ul>
      {items.map((item, i) => (
        <ListItem id={i}>
          <Anchor value={item} />
        </ListItem>
      ))}
    </ul>
  );
}
function ListItem({ children }) {
  return <li>{children}</li>;
}
function Anchor({ value }) {
  return <a href="#">{value}</a>;
}
function App() {
  return <List items={[1, 2, 3, 4, 5]} />;
}
export default App;

And we’re also going to need an entry point which we can execute once the code is compiled. Just like a regular index.js in a React application, we are going to invoke a render function provided by our custom runtime, and that function takes two parameters, the top most component and a DOM node in which the app will be rendered. In a React application, that function would come from react-dom or react-native , here we’re going to write our own.

// src/index.js
import { render } from "../runtime/jsx-runtime";
import App from "./App";
import { JSDOM } from "jsdom";
// our jsdom document
const dom = new JSDOM(`<!DOCTYPE html><body><div id='root'/></body>`);
const { document } = dom.window;
const rootElement = document.getElementById("root");
render(<App />, rootElement);
console.log(document.body.innerHTML);

Let’s create two npm scripts, one to build the code and one to execute it.

"scripts": {
    "build": "babel src -d lib",
    "start": "node -r esm lib"
  },

The build task compiles everything that is in src to output it in lib , and the start task runs the compiled code located in the lib folder.

Before writing the runtime, let’s build the code. As the name implies, we don’t need the runtime to build the code, only execute it. To compile the code, we use babel and the jsx transform plugin we configured in the .babelrc file

$ npm run build
> babel src -d lib
Successfully compiled 2 files with Babel (239ms).

Let’s look at a snippet from the output file, it’ll tell us how the runtime is invoked:

// lib/App.js
import { jsx as _jsx } from "../runtime/jsx-runtime";
function List({
  items
}) {
  return _jsx("ul", {
    children: items.map((item, i) => _jsx(ListItem, {
      id: i,
      children: _jsx(Anchor, {
        value: item
      })
    }))
  });
}
//...
function App() {
  return _jsx(List, {
    items: [1, 2, 3, 4, 5]
  });
}
export default App;

We see the path to the runtime being picked up from .babelrc and we see that a jsx function exported from a jsx-runtime module is expected by the runtime. It takes two parameters, a node that can be a string or another component (function), and props.

We’re going to write the runtime by heavily reusing the code written by Rodrigo Pombo in his article “Build your own React”.

// runtime/jsx-runtime.js
function jsx(type, config) {
  if (typeof type === "function") {
    return type(config);
  }
const { children = [], ...props } = config;
  const childrenProps = [].concat(children);
  return {
    type,
    props: {
      ...props,
      children: childrenProps.map((child) =>
        typeof child === "object" ? child : createTextElement(child)
      ),
    },
  };
}
function createTextElement(text) {
  return {
    type: "TEXT_ELEMENT",
    props: {
      nodeValue: text,
      children: [],
    },
  };
}

I’m not going to go into much details here, just know that we recursively execute each function until it resolves to a string (“il”, “ul”, etc…) that can be used to make an object used to build an HTMLElement.

And if we look at the compiled index.js, we see that our initial render call was transformed to this:

// lib/index.js
render(_jsx(App, {}), rootElement);

And that’s how we’re going to code our render function, again with few changes from Rodrigo Pombo's article “Build your own React”. We know the render function receives the result of the jsx function we just coded.

// runtime/jsx-runtime.js
function render(element, container) {
  const dom =
    element.type === "TEXT_ELEMENT"
      ? container.ownerDocument.createTextNode("")
      : container.ownerDocument.createElement(element.type);
  const isProperty = (key) => key !== "children";
  Object.keys(element.props)
    .filter(isProperty)
    .forEach((name) => {
      dom[name] = element.props[name];
    });
  element.props.children.forEach((child) => render(child, dom));
  container.appendChild(dom);
}
export { jsx, render };

Again, not going to go into too much details here, we recursively traverse the structure generated from the transpiled jsx code and convert each element to an HTMLElement using jsdom.

Now when we run the code, we’ll see this the result of the execution:

$ npm start
> node -r esm lib
<div id="root"><ul><li><a href="#">1</a></li><li><a href="#">2</a></li><li><a href="#">3</a></li><li><a href="#">4</a></li><li><a href="#">5</a></li></ul></div>

And that’s it!

Now to recap what we just did:

We wrote a sample app using JSX, and no other import (src/App.js ).
We configured babel to compile our app using the new automatic mode, and specified our own custom runtime.
We wrote a custom runtime to execute the transpiled code and output it to HTML in the console.

Why is this a big deal? It’s not that big a change after all, right?

Well it’s a big deal because it means JSX can be used without React. That was already true previously (Rodrigo Pombo does it in his article where he creates a React clone called Didact, and Preact also uses JSX), but now it’s made particularly easy, and this opens many doors. We could see JSX in other frameworks than React, and it also means JSX can be used to render other things than just HTML. By decoupling the runtime from the code, we can use the same JSX to achieve different goals just by using a different runtime. Previously, we were bound to whatever import was made in the component.

I’m very impatient to see what will come from this change in the weeks and months to come. Also noteworthy is that this was not made in a bubble, the people behind babel and React worked on this together, and the automatic mode will become the default option in Babel 8. The maintainers behind TypeScript, Create React App, Next.js, Gatsby, ESLint and Flow also pitched in and adopted the changes, and the RFC process was open to community feedback.

Thanks for reading, and let me know if you have any questions in the comments.

Don't await in loops

Arnaud — Mon, 03 Aug 2020 22:27:37 +0000

In software development, a very common task is to perform an operation on each element of an iterable:

for (let i = 0; i < array.length; i++) {
  work(array[i]);
}

When introducing asynchronous operations, it's easy to write:

for (let i = 0; i < array.length; i++) {
  const result = await work(array[i]);
  doSomething(result);
}

However, this is far from optimal as each successive operation will not start until the previous one has completed.

Imagine the work function takes 100ms more than its previous execution:

const work = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

for (let i = 0; i < 10; i += 1) {
  await work((i + 1) * 100);
}

The first call will take 100ms, the second 200ms, and so on. The entire loop will be equal to the sum of the duration of each asynchronous operation, about 5.5 seconds!

Since work is asynchronous, we can use Promise.all to execute all the operations in parallel. All we need to do is add the promises to an array and call Promise.all

const p = [];
for (let i = 0; i < 10; i += 1) {
  p.push(work((i + 1) * 100));
}
const results = await Promise.all(p);

Now the entire loop will be as slow as its slowest operation, in our case this is ~1 second, 5.5x faster!

However, Promise.all does have one problem. It will reject immediately upon any of the input promises rejecting.

try {
  const p = [
    new Promise((resolve, reject) => setTimeout(() => reject(new Error('Failure!')), 200)),
  ];
  for (let i = 0; i < 10; i += 1) {
    p.push(work((i + 1) * 100));
  }
  const results = await Promise.all(p);
  console.log(results); // <- never executed !
} catch (error) {
  console.error(error.message); // Error: Failure!
}

There is only one little change needed to get all promises to run. We need to add a catch to each promise to handle the failures of the failed promises, and let the other promises resolve.

const errorHandler = (e) => e;

const p = [
  new Promise((resolve, reject) => {
    setTimeout(() => reject(new Error('Failure!')), 200);
  }).catch(errorHandler),
];
for (let i = 0; i < 10; i += 1) {
  p.push(work((i + 1) * 100).catch(errorHandler));
}
const results = await Promise.all(p);

results.forEach((result, i) => {
  if (result instanceof Error) {
    console.log(`Call ${i} failed`);
    return;
  }
  console.log(`Call ${i} succeeded`);
});

Notice how a new Error is passed to the reject callback. The handler simply returns the error, but this would also be a good place to log it. If in the handler the error were thrown instead, then we would default back to the previous behavior where the catch block would be entered.

We should always do our best to execute asynchronous operations in parallel, and we've seen that with proper error handling, it is possible to use Promise.all to execute a bunch of promises in parallel, even if one fails.

Happy coding!

Using Array.prototype.includes() vs Set.prototype.has() to filter arrays

Arnaud — Thu, 02 Jul 2020 20:05:56 +0000

During a code review, I noticed a piece of code that was calling includes inside filter.

The code looked something like this:

const valuesToKeep = [2, 4];
const valuesToTest = [1, 2, 3, 4];
const values = valuesToTest.filter((n) => valuesToKeep.includes(n)); // [2, 4]

The comment I left was along the lines:

"Hey, be careful, filter is O(n) and includes is O(n) so this is O(n2). This would perform as O(n) if you used a Set, BUT since the arrays are so small it probably does not make a difference".

To illustrate the comment with code, this is what I had in mind:

const valuesToKeep = [2, 4];
const valuesToTest = [1, 2, 3, 4];
const setToKeep = new Set(valuesToKeep);
const values = valuesToTest.filter((n) => setToKeep.has(n)); // [2, 4]

My comment didn't sit well with me because saying "hey this will perform OK because the data is a certain way" is not a good idea: the data may change, or maybe I'm just wrong.

So I decided to put this to test. I'm going to generate two arrays containing random integers: an array of values to keep, and an array of values to test. The premise is that the array of values to keep is much smaller than the array of values to test, so we're going to make the array of values to test 10 times bigger than the array of values to keep.

// array of values to keep
const valuesToKeep = Array.from({ length: LENGTH }, () => getRandomInt());

// array of values to check
const valuesToTest = Array.from({ length: LENGTH * 10 }, () =>
  getRandomInt()
);

Then we're going to run two tests: one using includes, and one using has, and we're going to start with LENGTH at 10, and increase it every time, as my premise is that for small array it won't matter much, but we want to see WHEN it starts mattering:

// filter using includes
console.time("includes");
valuesToTest.filter((v) => valuesToKeep.includes(v)); // n2
console.timeEnd("includes");

// filter using has
console.time("has");
const valuesToKeepSet = new Set(valuesToKeep);
valuesToTest.filter((v) => valuesToKeepSet.has(v)); // n
console.timeEnd("has");

And here are the results:

Length of values to keep:  1
Length of values to test:  10
includes: 0.207ms
has: 0.190ms

Length of values to keep:  10
Length of values to test:  100
includes: 0.020ms
has: 0.017ms

Length of values to keep:  100
Length of values to test:  1000
includes: 0.204ms
has: 0.071ms

Length of values to keep:  1000
Length of values to test:  10000
includes: 9.942ms
has: 1.307ms

Length of values to keep:  10000
Length of values to test:  100000
includes: 131.686ms
has: 8.016ms

Length of values to keep:  100000
Length of values to test:  1000000
includes: 1324.318ms
has: 71.495ms

So yes, I am right that with a small quantity of data, Array.includes and Set.has perform roughly the same, but we can see how quickly performance degrades, and the change is so small that it's hard to justify not making it, even for small data samples. Should the size of the data increase, especially the size of the valuesToKeep array, the code is future proof.

TLDR: when matching a value against a list of values, convert the Array to a Set first.

Untangle async calls from the try/catch block

Arnaud — Wed, 17 Jun 2020 15:33:06 +0000

Promises are resolved using a then/catch block like so:

myPromise
  .then((data) => {
    // promise resolved
    doStuff(data);
  })
  .catch((error) => {
    // promise rejected
    throw error;
  });

The async/await keywords came along, and handling promises became a little easier, the code above can now be written like this:

try {
  const data = await myPromise;
  // promise resolved
  doStuff(data);
} catch (error) {
  // promise rejected
  throw error;
}

While this is arguably better, the try/catch block becomes really tiring to write after a while, so I've taken some inspiration from node to simplify this code a little bit. Node uses an idiomatic pattern called Error-first callbacks. By convention, callbacks get two parameters: the first one is the error, and the second one is the data. Our examples above also have an error and a data, so let's see how we can rewrite this:

const doAwait = async (promise) => {
  try {
    const data = await promise;
    return [undefined, data];
  } catch (error) {
    return [error, undefined];
  }
};

The doAwait function takes a promise, and returns an array with two elements, the first one is the error, and the second one is the data.

Using this simple function spares developers from writing try/catch blocks over and over again, and can just destructure the returned value into an array, and handle the error in a way that is similar to how callbacks are written in node:

const [error, result] = await doAwait(myPromise);

if (error) {
  throw error;
}

doStuff(result);

I find this little function quite handy, and the npm package to-await actually does just that, and it also provides a handy utility to resolve an array of promises! Visit its README for more code examples.