cdk-nextjs 0.7.0 → 0.7.2

package/lib/nextjs-build/nextjs-build.d.ts

@@ -209,6 +209,16 @@ export declare class NextjsBuild extends Construct {
      * function that cannot serve it) is this, several steps downstream.
      */
     private resolveDeploymentRoots;
+    /**
+     * `next build` traces native addons from the machine it runs on, and only
+     * `sharp` is swapped for the target. Anything else built for another platform
+     * fails with MODULE_NOT_FOUND or ERR_DLOPEN_FAILED on the first request that
+     * loads it, so say which package at synth. A warning, not an error: some
+     * addons are optional (`ws`'s `bufferutil`, `fsevents`) and fall back to JS.
+     *
+     * Only the OS and CPU are checked: glibc and musl builds share a header.
+     */
+    private warnOnForeignNativeBinaries;
     /**
      * Lambda enforces 250 MB unzipped at CloudFormation time, which is minutes
      * into a deploy and reports only a size. Splitting exists to stay under that
@@ -414,6 +424,21 @@ export declare function sharpBinaryDir(root: string): string;
  * monorepo.
  */
 export declare function listTree(root: string): Dirent[];
+/**
+ * The platform a native addon was compiled for, read from its header:
+ * `linux-<arch>`, `darwin` or `win32`, or `undefined` for a file that is none
+ * of those.
+ */
+export declare function nativeBinaryPlatform(file: string): string | undefined;
+/**
+ * The packages under `root` that have `.node` addons but none built for
+ * `target`, so they'd fail to load there. Returned as `root`-relative paths.
+ *
+ * A package with addons for several platforms is fine as long as one of them
+ * is `target`: packages like `bufferutil` bundle a `darwin` and a
+ * `linux-x64` addon and load whichever matches the machine.
+ */
+export declare function findForeignNativePackages(root: string, target: string): string[];
 /**
  * Write {@link PUBLIC_FILES_FILE_NAME} into a deployment root's runtime
  * directory: every file under `publicDir`, listed the way the runtime would