How does Promise.resolve(value) differ from new Promise(resolve => resolve(value)), and what does Promise.resolve return when the argument is already a native promise?

## Two ways to make an already-decided promise The constructor exists for wrapping something that is not yet promise-shaped — a callback API, a timer, an event. When you already have the value, the static methods are the direct route: ```js const a = Promise.resolve(1); const b = new Promise((resolve) => resolve(1)); // both fulfilled with 1 ``` For a plain value the two are equivalent in behaviour, and the static form is simply clearer and cheaper: no executor closure, no ceremony. ## The identity short-circuit The difference appears when the argument is itself a promise. `Promise.resolve` performs an identity check: if the argument is a promise *and* its `constructor` property is the same constructor `Promise.resolve` was called on, it hands the argument straight back. ```js const inner = Promise.resolve(1); Promise.resolve(inner) === inner; // true new Promise((resolve) => resolve(inner)) === inner; // false ``` In the constructor case a genuinely new promise object is created; calling `resolve(inner)` makes that new promise *track* `inner`, so it settles with the same outcome, but it is a distinct object and settles a turn later than `inner` does. The short-circuit is not merely an optimisation you can ignore. It means `Promise.resolve` is idempotent — feeding a promise through it repeatedly costs nothing and never adds layers. ## Why the check is constructor-sensitive The rule is deliberately conservative: the argument is returned as-is only when its `constructor` matches. A subclass instance passed to `Promise.resolve` is *not* returned unchanged, because the caller asked for a base `Promise` and getting back a subclass could carry different behaviour: ```js class MyPromise extends Promise {} const m = MyPromise.resolve(1); Promise.resolve(m) === m; // false — constructors differ MyPromise.resolve(m) === m; // true — same constructor ``` ## The normalisation idiom The most common real use is smoothing over an API that may return either a value or a promise: ```js function run(handler, input) { return Promise.resolve(handler(input)).then((out) => log(out)); } ``` If `handler` is synchronous you still get a promise; if it is asynchronous you get its promise back untouched, with no extra wrapper. This is how plugin and middleware layers accept both styles without branching on the return type. A related idiom is starting a chain from a constant, so that everything downstream is uniform: `Promise.resolve(seed).then(step1).then(step2)`. One caveat: `Promise.resolve(handler(input))` does not protect you from a *synchronous* throw inside `handler` — the call happens before `Promise.resolve` is ever reached, so the exception escapes as an ordinary exception rather than a rejection. ## Promise.reject is not symmetric It is tempting to assume `Promise.reject` mirrors `Promise.resolve`. It does not: ```js const wrapped = Promise.reject(new Error('x')); const outer = Promise.reject(wrapped); // outer is rejected WITH the promise object, not with the Error ``` There is no identity check and no unwrapping: whatever you pass becomes the rejection reason verbatim. That asymmetry is intentional. Resolution has to inspect its argument anyway, because resolving with a thenable means adopting its outcome; rejection has no such concept, so the reason is stored as an opaque value. The practical rule is to always pass `Promise.reject` an `Error` — passing a promise, a string, or a plain object produces a reason that is awkward to handle and loses the stack trace. A second practical note: `Promise.reject(...)` creates an already-rejected promise, and if you build one and do not attach a handler promptly, the runtime reports it as an unhandled rejection. ## Choosing between them Use the constructor only when you are genuinely bridging something non-promise into promise-land, and there is a callback or event whose completion you must translate into a `resolve`/`reject` call. Everything else — a known value, a value that might already be a promise, an immediate failure — is better expressed with `Promise.resolve` or `Promise.reject`. Reaching for `new Promise` around code that already returns a promise is a well-known anti-pattern: it adds an object, an extra settlement hop, and a chance to lose an error by forgetting to wire the rejection path.