In Node, fs.readFile(path, encoding, callback) reports its result through an error-first callback (err, data). How would you wrap that call so it returns a Promise instead, and what rules keep such a wrapper correct?

## What "error-first" means Node's traditional asynchronous APIs share one calling convention: the last argument is a function invoked with the failure as its first parameter and the successful result after it. `fs.readFile('a.txt', 'utf8', (err, data) => ...)` calls back either with `err` set to an `Error` and `data` undefined, or with `err` null and `data` holding the contents. Exactly one of those happens, and it happens exactly once. Promisifying means turning that convention into the other one: a rejected promise for the first case, a fulfilled promise for the second. ## The wrapper ```js import fs from 'node:fs'; function readFileAsync(path, encoding) { return new Promise((resolve, reject) => { fs.readFile(path, encoding, (err, data) => { if (err) reject(err); else resolve(data); }); }); } ``` The whole job of the executor — the function passed to `new Promise` — is that translation. It receives two functions from the constructor: `resolve`, which fulfils the promise with a value, and `reject`, which rejects it with a reason. Every path through the callback must reach exactly one of them. ## The executor runs synchronously The executor is invoked immediately by the `Promise` constructor, before `new Promise` returns and therefore before `readFileAsync` returns. So the read starts at the moment you call the function, not when someone attaches `.then` or `await`. Promises are not lazy tasks: they are handles on work that is already running. That is worth saying out loud in an interview, because a common wrong model is that `await` "starts" the operation. ## Settle exactly once Once a promise is settled its state is fixed. Calling `resolve` a second time, or calling `reject` after `resolve`, does nothing at all — no exception, no warning, no console output. That immutability is a feature: a consumer can never see a promise flip from fulfilled to rejected. It is also a hazard for a wrapper author, because it hides bugs. If the underlying API mistakenly calls back twice, or you forget the `else` so a truthy `err` runs both branches, the wrapper looks fine and the second signal simply vanishes. When you suspect a misbehaving callback API, add an explicit `let settled = false` guard that logs rather than swallowing. ## Keep the executor thin The constructor wraps only the *synchronous* run of the executor in an implicit try/catch: if the executor throws before it returns, the promise rejects with that value. The moment the callback fires — one or more turns of the event loop later — that protection is gone. A throw inside the callback escapes into the host: in Node it surfaces as an uncaught exception, which by default prints the stack and exits the process, and the promise stays pending forever. So resist the temptation to do work there: ```js // don't parse inside the executor's callback readFileAsync('config.json', 'utf8').then(text => JSON.parse(text)); ``` A `JSON.parse` failure in the `.then` becomes a normal rejection that `catch` can handle; the same failure inside the executor's callback does not. ## Callbacks that are not error-first Some APIs take two separate callbacks, one for success and one for failure. Those wrap even more tersely, because `resolve` and `reject` are ordinary functions you can hand over directly: ```js function load(id) { return new Promise((resolve, reject) => api.load(id, resolve, reject)); } ``` The only caution is that `resolve` accepts a single value, so an API that calls its success callback with several arguments loses all but the first unless you wrap them yourself: `(a, b) => resolve({ a, b })`. ## Prefer the promise API that already exists Most of the time you should not write this code at all. Node ships promise-native modules — `node:fs/promises`, `node:timers/promises`, `node:dns/promises` — and `util.promisify` mechanises the error-first case for anything else. Hand-rolling is for third-party or legacy APIs with no promise form. And never wrap something that already returns a promise: `return original()` is the correct "wrapper". ## The generic helper Written out, the generic version is the same three lines applied to any arity: ```js function promisify(fn) { return (...args) => new Promise((resolve, reject) => { fn(...args, (err, value) => (err ? reject(err) : resolve(value))); }); } ``` That toy version already shows why the built-in exists: it drops any extra callback arguments, and it does not forward the receiver, so promisifying a method and calling it detached loses `this`.