Building NSIS installers broken after switching from 22.10.5 to 22.11.1

• Version: 22.11.1

• Electron Version: 12.0.6
• Electron Type (current, beta, nightly): current

• Target: Windows, NSIS, x64

After updating electron-builder from 22.10.5 to 22.11.1, this error started happening for all of our Windows builds:

  • packager.vm is used: Cannot read property 'readFileSync' of undefined
(node:90934) UnhandledPromiseRejectionWarning: Error: Exit code: ENOENT. spawn prlctl ENOENT
    at /path/to/project/node_modules/builder-util/src/util.ts:132:18
    at exithandler (child_process.js:315:5)
    at ChildProcess.errorhandler (child_process.js:327:5)
    at ChildProcess.emit (events.js:315:20)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:275:12)
    at onErrorNT (internal/child_process.js:465:16)
    at processTicksAndRejections (internal/process/task_queues.js:80:21)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:90934) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:90934) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

After some digging, this seems to be an issue with how app-builder-lib’s TypeScript source is being compiled for distribution. The original source looks like this:

// ...

import fs from "fs"

// ...

export class UninstallerReader {
  // noinspection SpellCheckingInspection
  static exec(installerPath: string, uninstallerPath: string) {
    const buffer = fs.readFileSync(installerPath)

    // ...
  }
}

But in 22.11.1 this is being compiled to JavaScript that looks like this, where it expects the fs module to have a .default property, which it doesn’t (basically assuming it’s an ES module):

// ...

const fs_2 = require("fs");

// ...

class UninstallerReader {
    // noinspection SpellCheckingInspection
    static exec(installerPath, uninstallerPath) {
        const buffer = fs_2.default.readFileSync(installerPath); // <-- fs_2.default is undefined here

        // ...
    }
}

Looking at the distributed Javascript for the previous version (22.10.5), it seems like this case is handled by the compiled output:

// ...

var _fs2 = _interopRequireDefault(require("fs"));

// ...

function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }

// ...

class UninstallerReader {
  // noinspection SpellCheckingInspection
  static exec(installerPath, uninstallerPath) {
    const buffer = _fs2.default.readFileSync(installerPath);

    // ...
  }

}

The _interopRequireDefault function seems to be something that used to be added by @babel/plugin-transform-modules-commonjs. My current theory is that something broke the Babel integration between these two versions.

[omarkilani]

@mmaietta ah, okay. Yeah it works great on 22.10.4.

https://github.com/electron-userland/electron-builder/issues/5668#issuecomment-826941928

Forgot about that because I’m on a M1 Mac, though it looks like @develar made some other changes there that might help.

[ezzatron]

Can confirm that the original issue is now fixed for me. Thanks for the hard work 👍