Is there a way to execute bundled Node.js CLI scripts?

There are various issues related to executing bundled executables where the suggested solution appears to be to extract the executable to the host filesystem and run it there.

My question is: Is there a way to execute bundled node.js script binaries?

Use case: I need to run pm2’s pm2 binary to make use of the startup and monitor functionality. e.g.,

  // Launch pm2 monit.
  const options = {
    env: process.env,
    stdio: 'inherit'  // Display output.
  }

  try {
    childProcess.execSync(`sudo ${pm2Path} monit`, options)
  } catch (error) {
    console.log(`\n 👿 Failed to launch the process monitor.\n`)
    process.exit(1)
  }
  process.exit(0)

This fails with node_modules/pm2/bin/pm2 not being found. That file is a Javascript binary:

#!/usr/bin/env node
'use strict';

var semver = require('semver');

if (semver.satisfies(process.versions.node, '>= 6.0.0'))
  require('v8-compile-cache');

process.env.PM2_USAGE = 'CLI';
// etc.

So if I extract and run it, I would assume it would require Node to be installed (?)

Is there a way I can run this directly without extracting it? Or can such functionality be added?

Thanks in advance + thank you for Nexe; it’s excellent 😃

[calebboyd]

If you’re going this route, there are options for that!

Something like: nexe bootstrap.js -r app-deps.zip. If bootstrap depends on your application code you can use --no-bundle to prevent analysis (and inclusion) of its dependencies.

[aral]

<strike>Just a quick update: I finally got my app working. A quick overview of how in case it helps anyone else:

1. Zip up the whole app (excluding the .git folder) into my-app.zip
2. Include my-app.zip as a resource using nexe.
3. On first-run, use fs.readFileSync() and fs.writeFileSync() to copy the app’s source code (my-app.zip) to an external directory (e.g., ~/.my-app)
4. Launch PM2 from that external directory and make it launch the daemon from that directory also.

Now that it works, I don’t see why the actual app needs to be wrapped at all. Instead, I am going to create a tiny bootstrap script that copies and extracts the source zip and then forks to the main script from the external directory. (Not sure if that will introduce any other issues but it should reduce the size of the binary considerably as the code won’t be included twice.)</strike>

I was getting false successful runs as I hadn’t deactivated NVM/node on the current shell so execSync() was using the installed node instance. 🤦‍♂️

The problem was that I was using execSync(), which launches a shell, insted of fork() as you recommended, Caleb. The latter does error if I access the process object after launching the fork (Error: setRawMode EIO) but I’ve now refactored so I don’t do that and it seems to be working.

So no need for the convoluted process I outlined above (which wasn’t really working anyway).

Related: #607