.

node_modules/next/dist/server/node-environment-extensions/fast-set-immediate.external.d.ts

@@ -0,0 +1,73 @@
+declare const originalSetImmediate: typeof setImmediate;
+/**
+ * **WARNING: This function changes the usual behavior of the event loop!**
+ * **Be VERY careful about where you call it.**
+ *
+ * Starts capturing calls to `setImmediate` to run them as "fast immediates".
+ * All calls captured in this way will be executed after the current task
+ * (after callbacks from `process.nextTick()`, microtasks, and nextTicks scheduled from microtasks).
+ * This function needs to be called again in each task that needs the
+ * "fast immediates" behavior.
+ *
+ * ### Motivation
+ *
+ * We don't want `setImmediate` to be considered IO in Cache Components.
+ * To achieve this in a staged (pre)render, we want to allow immediates scheduled
+ * in stage N to run before stage N+1.
+ * Since we schedule stages using sequential `setTimeout`, this isn't possible without
+ * intercepting `setImmediate` and doing the scheduling on our own.
+ * We refer to this as a "fast immediate".
+ *
+ * Notably, this affects React's `scheduleWork` in render, which uses `setImmediate`.
+ * This is desirable -- if async work was scheduled during a stage, then it should
+ * get to run before we finish that stage.
+ *
+ * ### Example
+ *
+ * ```ts
+ * setTimeout(() => {
+ *   runPendingImmediatesAfterCurrentTask()
+ *   console.log("timeout 1")
+ *   setImmediate(() => {
+ *     console.log("immediate!!!")
+ *   })
+ * })
+ * setTimeout(() => {
+ *   console.log("timeout 2")
+ * })
+ * ```
+ * will print
+ *
+ * ```
+ * timeout 1
+ * immediate!!!
+ * timeout 2
+ * ```
+ *
+ * instead of the usual order
+ * ```
+ * timeout 1
+ * timeout 2
+ * immediate!!!
+ * ```
+ * > **NOTE**
+ * > The above is *most common* order, but it's not guaranteed.
+ * > Under some circumstances (e.g. when the event loop is blocked on CPU work),
+ * > Node will reorder things and run the immediate before timeout 2.
+ * > So, in a sense, we're just making this reordering happen consistently.
+ *
+ * Recursive `setImmediate` calls will also be executed as "fast immediates".
+ * If multiple immediates were scheduled, `process.nextTick()` (and associated microtasks)
+ * will be allowed to execute between them.
+ * See the unit tests for more examples.
+ * */
+export declare function DANGEROUSLY_runPendingImmediatesAfterCurrentTask(): void;
+/**
+ * This should always be called a task after `DANGEROUSLY_runPendingImmediatesAfterCurrentTask`
+ * to make sure that everything executed as expected and we're not left in an inconsistent state.
+ * Ideally, this wouldn't be necessary, but we're not in control of the event loop
+ * and need to guard against unexpected behaviors not forseen in this implementation,
+ * so we have to be defensive.
+ */
+export declare function expectNoPendingImmediates(): void;
+export { originalSetImmediate as unpatchedSetImmediate };