`npm install --save-dev` failed at `postinstall` stage

[xmliszt]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord. (Found similar issues, but none of them addressed my problem)

Describe the bug

When running npm install supabase --save-dev, the process hangs and then failed. The log shows that it fails at the postinstall stage with supabase@1.207.9 postinstall { code: 13, signal: null }.

I tried a lot of methods from online, all didn't actually work for me unfortunately. Things I have tried:

• different node version (tried v16, v18, v20)
• force clean npm cache
• delete package-lock.json and retry installing
• delete node_modules and retry installing
• completely uninstall node and npm and then re-install them
• manual overwrite npm registry
• restarted my MacBook
• factory reset my MacBook
• reset user permission for /usr directory
• check that no proxy has been configured for npm
• check that .npmrc file has no outdated access token or wrong registry (in fact currently I don't even have .npmrc in the $HOME so it should be running default settings!)

Here are some additional information that might help:

• My MacBook is M1 Pro MacBook Pro (Running on Sequoia 15.1)
• node version currently use via NVM : v20.10.0
• npm version: 10.2.3
• supabase cli version: @latest

Some observations:

1. running sudo npm install supabase --save-dev works for me. Therefore, I suspect does supabase cli postinstall script tries to access some files that require higher privileges?
2. running npm install supabase@1.89.1 --save-dev works for me too. Therefore, suspect there is some update to the postinstall.js script between the latest version and the v1.1 version such that this bug is introduced?
3. managed to find out that v1.89.1 works for me and then v1.90.0 failed. So there is some changes introduced in v1.90.0 that causes this to happen? -- I drilled down and found that this particular commit 571f336 causes subsequent version installation to fail.
   

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

1. Run npm install supabase@latest --save-dev
2. The npm process will hang when it reaches run supabase@1.207.9 postinstall step
3. And then it will fail after hanging for some time T_T

(However, this might not be reproducible for you because I have used some other laptops to try, and they all can install successfully 😭 I really don't know what happened to my device)

Expected behavior

Running npm install supabase@latest --save-dev should succeed.

Screenshots

Here is the error log for my last npm run npm install supabase --save-dev (I removed some lines that are not related to this package)

npm WARN deprecated @humanwhocodes/config-array@0.11.14: Use @eslint/config-array instead
npm WARN deprecated abab@2.0.6: Use your platform's native atob() and btoa() methods instead
npm WARN deprecated fsevents@2.1.3: "Please update to latest v2.3 or v2.2"
npm WARN deprecated @humanwhocodes/object-schema@2.0.3: Use @eslint/object-schema instead
npm WARN deprecated domexception@4.0.0: Use your platform's native DOMException instead
npm http fetch GET 200 https://registry.npmjs.org/resolve-from/-/resolve-from-4.0.0.tgz 2924ms (cache miss)
npm http fetch GET 200 https://registry.npmjs.org/util-deprecate/-/util-deprecate-1.0.2.tgz 2929ms (cache miss)
npm http fetch GET 200 https://registry.npmjs.org/path-key/-/path-key-3.1.1.tgz 2928ms (cache miss)
npm http fetch GET 200 https://registry.npmjs.org/untildify/-/untildify-4.0.0.tgz 2935ms (cache miss)
npm http fetch GET 200 https://registry.npmjs.org/set-blocking/-/set-blocking-2.0.0.tgz 2932ms (cache miss)
npm WARN deprecated debug@4.1.1: Debug versions >=3.2.0 <3.2.7 || >=4 <4.3.1 have a low-severity ReDos regression when used in a Node.js environment. It is recommended you upgrade to 3.2.7 or 4.3.1. (https://github.com/visionmedia/debug/issues/797)
npm http fetch GET 200 https://registry.npmjs.org/strip-bom/-/strip-bom-3.0.0.tgz 2940ms (cache miss)
npm http fetch GET 200 https://registry.npmjs.org/reusify/-/reusify-1.0.4.tgz 2976ms (cache miss)
npm http fetch GET 200 https://registry.npmjs.org/static-eval/-/static-eval-2.0.2.tgz 2998ms (cache miss)
npm http fetch GET 200 https://registry.npmjs.org/statuses/-/statuses-1.5.0.tgz 3010ms (cache miss)
npm http fetch GET 200 https://registry.npmjs.org/type-detect/-/type-detect-4.0.8.tgz 3028ms (cache miss)
npm http fetch GET 200 https://registry.npmjs.org/react-is/-/react-is-16.13.1.tgz 3065ms (cache miss)
npm http fetch GET 200 https://registry.npmjs.org/node-fetch 785ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/jsonpath-plus 786ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/undici-types/-/undici-types-5.26.5.tgz 3570ms (cache miss)
npm http fetch GET 200 https://registry.npmjs.org/ts-deepcopy/-/ts-deepcopy-0.1.4.tgz 3652ms (cache miss)
npm http fetch GET 200 https://registry.npmjs.org/@vercel%2ffun 489ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/type-fest/-/type-fest-4.8.3.tgz 4273ms (cache miss)
npm http fetch GET 200 https://registry.npmjs.org/@tensorflow%2ftfjs-core 479ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/@mapbox%2fnode-pre-gyp 139ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/@vercel%2fnode 345ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/@vercel%2frouting-utils 1579ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/path-match 65ms (cache revalidated)
npm http fetch GET 200 https://registry.npmjs.org/@supabase%2fssr 442ms (cache revalidated)
npm info run bufferutil@4.0.8 install node_modules/bufferutil node-gyp-build
npm info run utf-8-validate@5.0.10 install node_modules/utf-8-validate node-gyp-build
npm http fetch GET 200 https://registry.npmjs.org/@ironclad%2frivet-core 1506ms (cache revalidated)
npm info run utf-8-validate@5.0.10 install { code: 0, signal: null }
npm http fetch GET 200 https://registry.npmjs.org/vercel 57ms (cache revalidated)
...
npm info run supabase@1.207.9 postinstall node_modules/supabase node scripts/postinstall.js
...
npm info run supabase@1.207.9 postinstall { code: 13, signal: null }
npm verb stack Error: command failed
npm verb stack     at ChildProcess.<anonymous> (/Users/yx/.nvm/versions/node/v20.10.0/lib/node_modules/npm/node_modules/@npmcli/promise-spawn/lib/index.js:53:27)
npm verb stack     at ChildProcess.emit (node:events:514:28)
npm verb stack     at maybeClose (node:internal/child_process:1105:16)
npm verb stack     at ChildProcess._handle.onexit (node:internal/child_process:305:5)
npm verb pkgid supabase@1.207.9
npm verb Darwin 24.1.0
npm verb node v20.10.0
npm verb npm  v10.2.3
npm ERR! code 13
npm ERR! command failed
npm ERR! command sh -c node scripts/postinstall.js
npm ERR! Downloading https://github.com/supabase/cli/releases/download/v1.207.9/supabase_darwin_arm64.tar.gz
npm ERR! Downloading https://github.com/supabase/cli/releases/download/v1.207.9/supabase_1.207.9_checksums.txt
npm verb exit 13
npm verb unfinished npm timer reify 1729781821448
npm verb unfinished npm timer reify:build 1729781829533
npm verb unfinished npm timer build 1729781829534
npm verb unfinished npm timer build:deps 1729781829534
npm verb unfinished npm timer build:run:postinstall 1729781830308
npm verb unfinished npm timer build:run:postinstall:node_modules/supabase 1729781830313
npm verb code 13

System information

• OS: macOS
• Version of supabase: 1.207.9
• Version of Node.js: v20.10.0
• Version of npm: 10.2.3
• M1 Pro MacBook Pro (Running on Sequoia 15.1)

[kbrgl]

I’m running into the same issue in a Vercel build. The issue is caused by the postinstall script in my case as well. Logs:

[11:09:29.860] Running build in Washington, D.C., USA (East) – iad1
[11:09:30.007] Cloning github.com/<REDACTED> (Branch: <REDACTED>, Commit: <REDACTED>)
[11:09:35.845] Warning: Failed to fetch one or more git submodules
[11:09:35.846] Cloning completed: 5.838s
[11:09:45.690] Restored build cache from previous deployment (<REDACTED>)
[11:09:45.773] Running "vercel build"
[11:09:46.445] Vercel CLI 37.12.0
[11:09:46.903] > Detected Turbo. Adjusting default settings...
[11:09:48.596] Running "install" command: `bun install`...
[11:09:48.803] bun install v1.1.30 (7996d06b)
[11:09:49.933] file:///vercel/path0/node_modules/tar/dist/esm/mkdir.js:3
[11:09:49.933] import { mkdirp, mkdirpSync } from 'mkdirp';
[11:09:49.933]          ^^^^^^
[11:09:49.933] SyntaxError: Named export 'mkdirp' not found. The requested module 'mkdirp' is a CommonJS module, which may not support all module.exports as named exports.
[11:09:49.933] CommonJS modules can always be imported via the default export, for example using:
[11:09:49.933] 
[11:09:49.933] import pkg from 'mkdirp';
[11:09:49.933] const { mkdirp, mkdirpSync } = pkg;
[11:09:49.933] 
[11:09:49.934]     at ModuleJob._instantiate (node:internal/modules/esm/module_job:123:21)
[11:09:49.934]     at async ModuleJob.run (node:internal/modules/esm/module_job:191:5)
[11:09:49.934]     at async ModuleLoader.import (node:internal/modules/esm/loader:337:24)
[11:09:49.934]     at async loadESM (node:internal/process/esm_loader:34:7)
[11:09:49.934]     at async handleMainPromise (node:internal/modules/run_main:106:12)
[11:09:49.934] 
[11:09:49.934] Node.js v18.20.4
[11:09:49.934] 
[11:09:49.934] error: postinstall script from "supabase" exited with 1
[11:09:49.941] Error: Command "bun install" exited with 1
[11:09:50.397] 

[kbrgl]

In case you're here: pinning 1.207.0 worked for me. A higher version between 1.207.0 and 1.207.9 might also work, I’d suggest trying it out.

[xmliszt]

In case you're here: pinning 1.207.0 worked for me. A higher version between 1.207.0 and 1.207.9 might also work, I’d suggest trying it out.

Thanks! I tried but unfortunately it still failed :( The latest version so far tested working for me is 1.89.1, 1.90.0 onwards cannot already. From the commit of 1.90.0 seems like the fetching checksum and verifying checksum was introduced so I'm not sure if my issue was caused by this.

[aloisklink]

I wonder if your OpenSSL library doesn't support sha256

cli/scripts/postinstall.js

Line 128 in 571f336

const hash = createHash("sha256");

(although it would be weird, since sha256 is a very common hash algorithm).

You can try running

openssl list -digest-algorithms

Alternatively, it's also possible that your version of Node.JS doesn't have crypto support (although I've only seen this before on IoT devices, not laptops!) Check out: https://nodejs.org/api/crypto.html#determining-if-crypto-support-is-unavailable

Try running the following function, just to sanity check sha256 and crypto works on your computer:

alois@pc:~$ node --eval="console.log(require('crypto').createHash('sha256').update('alice', 'utf8').digest())"
<Buffer 2b d8 06 c9 7f 0e 00 af 1a 1f c3 32 8f a7 63 a9 26 97 23 c8 db 8f ac 4f 93 af 71 db 18 6d 6e 90>

edit: It might be that sudo node and node are two different NodeJS binaries.

[xmliszt]

algorithms

Thank you @aloisklink ! I have an interesting discovery, and with the help with some Claude prompt, here is what I found:

I manually run the postinstall.js script with the same nodejs version (20.10.0), it results in the same hanging issue where the fetch stuck at fetching checksum file from GitHub.

However, if I switch the fetch order, so instead of fetching the zip file first, I fetch the checksum first. Keeping all other logics exactly the same, it does not require sudo anymore!

Here is my modified main function that works for me:

async function main() {
  const yarnGlobal = JSON.parse(
    process.env.npm_config_argv || "{}"
  ).original?.includes("global");
  if (process.env.npm_config_global || yarnGlobal) {
    throw errGlobal;
  }
  if (!arch || !platform) {
    throw errUnsupported;
  }

  const pkg = await readPackageJson();
  if (platform === "windows") {
    // Update bin path in package.json
    pkg.bin[pkg.name] += ".exe";
  }

  const binPath = pkg.bin[pkg.name];
  const binDir = path.dirname(binPath);
  await fs.promises.mkdir(binDir, { recursive: true });

  // First we will Un-GZip, then we will untar.
  const ungz = zlib.createGunzip();
  const binName = path.basename(binPath);
  const untar = extract({ cwd: binDir }, [binName]);

  const proxyUrl =
    process.env.npm_config_https_proxy ||
    process.env.npm_config_http_proxy ||
    process.env.npm_config_proxy;

  // Keeps the TCP connection alive when sending multiple requests
  // Ref: https://github.com/node-fetch/node-fetch/issues/1735
  const agent = proxyUrl
    ? new HttpsProxyAgent(proxyUrl, { keepAlive: true })
    : new Agent({ keepAlive: true });

  const hash = createHash("sha256");
  const pkgNameWithPlatform = `${pkg.name}_${platform}_${arch}.tar.gz`;
  const checksumMap = await fetchAndParseCheckSumFile(pkg, agent);

  const url = getDownloadUrl(pkg);
  console.info("Downloading", url);
  const resp = await fetch(url, { agent });

  resp.body
    .on("data", (chunk) => {
      hash.update(chunk);
    })
    .pipe(ungz);

  ungz
    .on("end", () => {
      const expectedChecksum = checksumMap?.[pkgNameWithPlatform];
      // Skip verification if we can't find the file checksum
      if (!expectedChecksum) {
        console.warn("Skipping checksum verification");
        return;
      }
      const calculatedChecksum = hash.digest("hex");
      if (calculatedChecksum !== expectedChecksum) {
        throw errChecksum;
      }
      console.info("Checksum verified.");
    })
    .pipe(untar);

  await new Promise((resolve, reject) => {
    untar.on("error", reject);
    untar.on("end", () => resolve());
  });

  // Link the binaries in postinstall to support yarn
  await binLinks({
    path: path.resolve("."),
    pkg: { ...pkg, bin: { [pkg.name]: binPath } },
  });

  console.info("Installed Supabase CLI successfully");
}

---

What Claude explained (which I'm not exactly sure if it makes sense but just gonna put it down here):

The reason this works is related to how Node.js handles connections and DNS caching. Here's why:

1. When you fetch the checksum first:

   • The initial DNS lookup and HTTPS connection to github.com is established
   • Node.js caches the DNS resolution
   • The TLS/SSL handshake is completed
   • The HTTPS agent keeps the connection alive (due to keepAlive: true)

2. When you then fetch the zip file:

   • It reuses the already established and verified connection
   • No new DNS lookup is needed
   • No new TLS handshake is needed
   • The larger file transfer happens on an already proven stable connection

When you did it in the reverse order:

1. The larger zip file download would start first
2. The DNS resolution might timeout or hang due to macOS security features
3. Since it's the first connection, there's no cached DNS or established connection
4. The larger file size means more time for things to go wrong during initial connection setup

The reason sudo worked is because:

• sudo bypasses some of macOS's security restrictions on DNS and networking
• It has different DNS resolution paths
• It has elevated network privileges

Best practices going forward:

// Good pattern
const checksumMap = await fetchAndParseCheckSumFile(pkg, agent); // Small file first
const resp = await fetch(url, { agent }); // Large file second

// Less reliable pattern
const resp = await fetch(url, { agent }); // Large file first
const checksumMap = await fetchAndParseCheckSumFile(pkg, agent); // Small file second

Always establish and verify connectivity with a small request before attempting large file transfers! This is actually a common practice in download managers and file transfer protocols.

---

Hope that will help with the investigation!