Recommended strategy for packaging Ink applications with pkg

[Niladri2003]

Thank you for the ink package it is really awesome ! :)
I am trying to distribute an Ink-based CLI as a single standalone binary using pkg (or @yao-pkg/pkg).

The Problem

Packaging Ink has become difficult for me due to the transition to ESM and the inclusion of Top-Level Await (TLA) in dependencies like yoga-layout. Specifically:

Top-Level Await: Modern versions of Ink/Yoga trigger ERR_REQUIRE_ASYNC_MODULE when bundled into a CommonJS format for pkg.

Resolution Errors: Even when using import(), pkg often fails to resolve internal Ink files (like render.js) from within its virtual snapshot filesystem.

What I've Tried

• Bundling with Rollup/NCC/esbuild: Attempted to flatten everything into a single .cjs file, but this is blocked by the Top-Level Await in the dependency tree.
• pkg with ESM: Attempted to point pkg to an ESM entry point, but it fails to handle dynamic imports/resolution within the snapshot.

Is there any recommended way to package and distribute clis build using ink and packaged using pkg ?

[ghoshbishakh]

This is very frustrating for us. We are still unable to package it using pkg because it needs cjs.

[clicktodev]

bun and deno support esm in executables

[jameslawson]

I'm also running into this problem.

It's really unfortunate that this library which is popular for CLIs does not let you create a CLI binary executable with either 1. Node.js's built in way (Node SEA), or 2. third party libraries (vercel/pkg or yao-pkg/pkg) AFAIK.

I spent hours trying both approaches and I haven't been able to make any progress. The reason pretty much boils down to the problem that both Node SEA and pkg/yao-pkg need a CJS bundle ... and working around top-level awaits used by this library has been a complete blocker.

I would really appreciate a version of this library without top-level await as moving our whole project to a new JavaScript runtime like bun to continue using ink is not really an ideal solution for us.

[sindresorhus]

Ink is a rendering library. Bundling/packaging is outside its scope. Node SEA has supported ESM since Node 22.8 (unflagged in 23+), and both Bun and Deno handle ESM executables natively. The pkg tool is unmaintained and CJS-only, that's a tooling limitation, not an Ink issue.

[clicktodev]

Bun recently added complete support for ESM, bytecode, and top level await for binaries and it's been working pretty well so far thanks to bun's compatibilty with node

[jameslawson]

In the end I switched to using bun (it was unfortunate as my team now has the overhead of maintaining both bun and node) - but it works great, and features like cross-compilation work smoothly in CI/CD. We're able to build our CLI tool and create releases very well with ink + bun.

I agree with sindresorhus, this is a fundamentally a tooling issue with Node.js being the culprit. I do see ESM as the future (despite the path for the community to adopt it being pretty rough), and I'm my opinion, it's another ESM/CJS migration painpoint that's been caused by Node.js. As sindresorhus mentioned, support for SEA+ESM has now dropped but I haven't tried it out. I'm not sure if it's been supported in v22/v23 though? Can anyone find where this is from?

I found v25.7.0 has added it and released it last week:

• Node.js PR adding ESM support to SEA (3 weeks ago): sea: support ESM entry point in SEA nodejs/node#61813
• Node v25.7.0 release (1 week ago): https://github.com/nodejs/node/releases/tag/v25.7.0
• https://nodejs.org/en/blog/release/v25.7.0
• Docs: https://nodejs.org/api/single-executable-applications.html

I encourage everyone in the thread to try it out Node v25.7.0 with ink and see if it solves their problem.
If I find time I'll try it out and post an example if I can get it working.

[Niladri2003]

Hi @jameslawson, thanks for providing this update for Node.js. I appreciate you sharing it—I'll give it a try.