With no changes, "Cannot find module 'appdmg'"

[busterbogheart]

Pre-flight checklist

• I have read the contribution documentation for this project.
• I agree to follow the code of conduct that this project uses.
• I have searched the issue tracker for a bug that matches the one I want to file, without success.

Electron Forge version

6.4.1

Electron version

v24.8.1

Operating system

macOS 11.3.1

Last known working Electron Forge version

6.1.1

Expected behavior

Our build is running in Circle CI, and without changes recently this issue happens. We've tried pegging the @electron-forge modules to 6.1.1, but the issue remains.

Any recent changes in forge that could cause the Cannot find module 'appdmg' error?

Actual behavior

 electron-forge:hook hook triggered: postPackage +20s
[SUCCESS] Running postPackage hook
[SUCCESS] Running package command
[STARTED] Running preMake hook
  electron-forge:hook hook triggered: preMake +1ms
[SUCCESS] Running preMake hook
[STARTED] Making distributables
  electron-forge:hook hook triggered: readPackageJson +1ms
[STARTED] Making a dmg distributable for darwin/x64
[FAILED] Cannot find module 'appdmg'
[FAILED] Require stack:
[FAILED] - /Users/distiller/repo/node_modules/electron-installer-dmg/src/index.js
[FAILED] - /Users/distiller/repo/node_modules/@electron-forge/maker-dmg/dist/MakerDMG.js
[FAILED] - /Users/distiller/repo/node_modules/@electron-forge/core/dist/util/require-search.js
[FAILED] - /Users/distiller/repo/node_modules/@electron-forge/core/dist/util/plugin-interface.js
[FAILED] - /Users/distiller/repo/node_modules/@electron-forge/core/dist/util/forge-config.js
[FAILED] - /Users/distiller/repo/node_modules/@electron-forge/core/dist/util/index.js
[FAILED] - /Users/distiller/repo/node_modules/@electron-forge/core/dist/api/index.js
[FAILED] - /Users/distiller/repo/node_modules/@electron-forge/cli/dist/electron-forge-publish.js

### Steps to reproduce

Unknown

### Additional information

_No response_

[erikian]

Looks like the appdmg package is not installed for some reason. If you cache your node_modules on CircleCI, you could try nuking the cache so the dependencies are reinstalled (that would also give you a log with some useful info if something goes wrong).

[RunDevelopment]

Hello, I have the same issue and would like to add some insight I gained while losing my sanity while investigating this issue.

I encountered this issue while working on chainner. I noticed that this Github actions workflow suddenly started failing on macOS when I changed a file totally unrelated to the workflow. I got the same error message as @busterbogheart:

[FAILED] Cannot find module 'appdmg'
[FAILED] Require stack:
[FAILED] - /Users/runner/work/chaiNNer/chaiNNer/node_modules/electron-installer-dmg/src/index.js
[FAILED] - /Users/runner/work/chaiNNer/chaiNNer/node_modules/@electron-forge/maker-dmg/dist/MakerDMG.js
...

While investigating this issue, I found 2 main things:

Firstly, the issue is definitely related to caches. Removing the cache: 'npm' from the workflow consistently triggered the issue.

Secondly, I noticed the logs of all successful and failed builds were identical until the Cannot find module 'appdmg' except for one detail: native dependencies. Here's the diff of 2 logs (one successful one not):

 [SUCCESS] Running prePackage hook from forgeConfig
 [STARTED] [plugin-webpack] Preparing native dependencies
 [TITLE] [plugin-webpack] Preparing native dependencies
-[TITLE] [plugin-webpack] Preparing native dependencies: 0 / 1
-[TITLE] [plugin-webpack] Preparing native dependencies: 1 / 1
-[SUCCESS] [plugin-webpack] Preparing native dependencies: 1 / 1
+[SUCCESS] [plugin-webpack] Preparing native dependencies
 [STARTED] [plugin-webpack] Building webpack bundles
 [SUCCESS] [plugin-webpack] Building webpack bundles
 [SUCCESS] Running prePackage hook
@@ -68,6 +66,55 @@
 [SUCCESS] Running preMake hook
 [STARTED] Making distributables
 [STARTED] Making a dmg distributable for darwin/universal
-[SUCCESS] Making a dmg distributable for darwin/universal
+[FAILED] Cannot find module 'appdmg'
+[FAILED] Require stack:
+[FAILED] - /Users/runner/work/chaiNNer/chaiNNer/node_modules/electron-installer-dmg/src/index.js
+[FAILED] - /Users/runner/work/chaiNNer/chaiNNer/node_modules/@electron-forge/maker-dmg/dist/MakerDMG.js
+...

As we can see, the successful runs always prepare one native dependency, while the failed runs do not. This native dependency is specific to macOS (my windows and linux runs never have it), so I suspect that appdmg is the native dependency.

[ashleyhindle]

I'm having this issue randomly also with GitHub actions. 1 hour to develop a new feature, 6+ hours trying to fix an npm issue :)

The issue seems to be with npm install/npm ci (at least in my case), as arborist/reify (used by @electron/rebuild says not to care about appdmg sometimes:

npm verb reify failed optional dependency /Users/runner/work/focusanchor/focusanchor/node_modules/appdmg
npm sill reify mark deleted [
npm sill reify   '/Users/runner/work/focusanchor/focusanchor/node_modules/appdmg',
npm sill reify   '/Users/runner/work/focusanchor/focusanchor/node_modules/.bin/appdmg'
npm sill reify ]

I can't figure out why it's not including appdmg.

---

I've tried updating forge.config to not use the cache, and to use appdmg as a forced module to rebuild:

  rebuildConfig: {
    force: true,
    useCache: true,
    extraModules: ['appdmg']
  },

I've added appdmg as a devdependency directly. I've updated electron-forge and all libraries to the latest versions.

I've updated GitHub actions to check if it's now returning different OS platform details so the appdmg 'os' setting wouldn't match, but that's all fine

    - name: Dump runner OS
      run: echo "${{ runner.os }}"
    - name: Dump NPM OS Platform
      run: node -e "console.log(os.platform());"

I've changed it to rm -rf node_modules before npm installing, just in case!

Nothing helps/works 😭

[ashleyhindle]

After removing Windows from my matrix the OSX build succeeds consistently 🤔

[MarshallOfSound]

@ashleyhindle if you're cachingnode_modules in any way the cache key needs to include platform, otherwise it sounds like you're restoring a cached set of windows node_modules onto your macos runner which won't have appdmg set up because that module is only installed on macos hosts

[ashleyhindle]

@ashleyhindle if you're cachingnode_modules in any way the cache key needs to include platform, otherwise it sounds like you're restoring a cached set of windows node_modules onto your macos runner which won't have appdmg set up because that module is only installed on macos hosts

Unfortunately I don't cache node_modules. Unfortunately nothing in my setup changed between my successful publish 2~ months ago, and my failed attempt today.

[davidjmeyer]

This is happening in my GitHub actions as well, Ive found that it correlates to the version of the Github runner.

macos-12: 20231029.1 causes a failure
macos-12: 20230921.1 produces a valid build

[bboure]

This issue happened to me today.

Solution was

npm i appdmg --save-optional

use --save-optional if you are building for different platforms.

Edit: It started failing again on the next build.

[ghost]

I am having this issue as well, not sure if I have anything meaningful to contribute as far as data points go.

[1000TurquoisePogs]

Hope the above helps those using github workflows. It seems to be caused by python.

[SpacingBat3]

@1000TurquoisePogs I end up with another issue after I've configured CI to install setuptools before npm ci and npm run make steps:

[STARTED] Making a dmg distributable for darwin/x64
[STARTED] Making a dmg distributable for darwin/arm64
[FAILED] Target already exists
[FAILED] Target already exists

An unhandled rejection has occurred inside Forge:
Error: Target already exists
at /Users/{user}/{projectPath}/{projectName}/node_modules/appdmg/lib/appdmg.js:80:53
    at node:fs:2313:7
    at FSReqCallback.oncomplete (node:fs:191:23)

I'm pretty sure this relates to LinusU/node-appdmg#130, although it is not an upstream error. It seems Forge should be the one taking care of cleanup and it's a problem in Forge it picks the path where it isn't possible to write to a file (since another file already exists there). Moreover, the overwrite flag that is announced in the upstream issue and PR seems to be an optional in the future and possibly set to false by default, which means an action from Forge maintainers might be necessary sooner or later.

Also, it is still failing for me on CI re-runs with older source code and lockfile (with both appdmg module issue and Target already exists ones), which makes this issue even more surprising and could mean a breakage either with the deps or in CI image I've been using.

[hopkins385]

Had the same issue on Mac. After hrs of tinkering, I tried to install the package manually via npm i -D appdmg and it failed, complaining about my python version 3.12. So, I changed my global python version to 3.11.4 via

pyenv global 3.11.4

And its working fine now. Hope this helps anyone else.

[jgresham]

Here is the fix if you want to keep 3.12 (github action default python versions) LinusU/node-appdmg#234

[jgresham]

It looks like GHA mac runner has installed brew and python in some new way which is now giving an error. The --break-system-packages flag fixes the error for me (I don't use python for other things in my actions) so my command is now: python3 -m pip install setuptools --break-system-packages

New error:

Run python3 -m pip install setuptools
  python3 -m pip install setuptools
  shell: /bin/bash -e {0}
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try brew install
    xyz, where xyz is the package you are trying to
    install.
    
    If you wish to install a Python library that isn't in Homebrew,
    use a virtual environment:
    
    python[3](https://github.com/NiceNode/nice-node/actions/runs/8803883604/job/24163039602#step:2:3) -m venv path/to/venv
    source path/to/venv/bin/activate
    python3 -m pip install xyz
    
    If you wish to install a Python application that isn't in Homebrew,
    it may be easiest to use 'pipx install xyz', which will manage a
    virtual environment for you. You can install pipx with
    
    brew install pipx
    
    You may restore the old behavior of pip by passing
    the '--break-system-packages' flag to pip, or by adding
    'break-system-packages = true' to your pip.conf file. The latter
    will permanently disable this error.
    
    If you disable this error, we STRONGLY recommend that you additionally
    pass the '--user' flag to pip, or set 'user = true' in your pip.conf
    file. Failure to do this can result in a broken Homebrew installation.
    
    Read more about this behavior here: <https://peps.python.org/pep-0[6](https://github.com/NiceNode/nice-node/actions/runs/8803883604/job/24163039602#step:2:7)68/>

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 66[8](https://github.com/NiceNode/nice-node/actions/runs/...) for the detailed specification.
Error: Process completed with exit code 1.

[RexWzh]

macos-12: 20230921.1

Thanks! It works for me:

    - name: Install Python 3.11.4
      uses: actions/setup-python@v4
      with:
        python-version: '3.11.4'

[eliandoran]

If using GitHub Actions with the macos-latest image, it is also possible to install the setuptools via brew to avoid downgrading the Python version:

      - name: Set up Python for appdmg to be installed
        run: brew install python-setuptools