forge icon indicating copy to clipboard operation
forge copied to clipboard

vscode-nix script cannot find the other executables

Open liamdawson opened this issue 5 years ago • 9 comments

Preflight Checklist

  • [x] I have read the contribution documentation for this project.
  • [x] I agree to follow the code of conduct that this project follows, as appropriate.
  • [x] I have searched the issue tracker for a bug that matches the one I want to file, without success.
    • I did find https://github.com/electron-userland/electron-forge/issues/535, the closing PR for this issue introduced the problem I'm experiencing.

Issue Details

  • Electron Forge Version:
    • 6.0.0-beta.47
  • Electron Version:
    • v7.1.7
  • Operating System:
    • macOS 10.15.2

Expected Behavior

Using the launch configuration from https://www.electronforge.io/advanced/debugging in VS Code enables debugging for the new application.

Actual Behavior

The launch configuration errors with:

/Users/liamdawson/w/orcharduml/node_modules/.bin/electron-forge-vscode-nix --inspect-brk=35706 
internal/modules/cjs/loader.js:638
    throw err;
    ^

Error: Cannot find module '/Users/liamdawson/w/@electron-forge/cli/dist/electron-forge-start'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
    at Function.Module._load (internal/modules/cjs/loader.js:562:25)
    at Function.Module.runMain (internal/modules/cjs/loader.js:831:12)
    at startup (internal/bootstrap/node.js:283:19)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:622:3)

To Reproduce

  • yarn v1.21.1
  • npm v6.13.4
  • node v10.16.3

Additional Information

I'm guessing it's related to something about package nesting and/or symlinks?

liamdawson avatar Dec 24 '19 05:12 liamdawson

same issue. The problem is Error: Cannot find module '/Users/liamdawson/w/@electron-forge/cli/dist/electron-forge-start' but it missing node_modules in path 🤔

kresli avatar Mar 19 '20 23:03 kresli

to fix it the electron-forge-vscode-nix file must be change from

#!/usr/bin/env bash
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

ARGS=$@
ARGS=${ARGS// /\~ \~}

node $DIR/../../../@electron-forge/cli/dist/electron-forge-start --vscode -- \~$ARGS\~

to

#!/usr/bin/env bash
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

ARGS=$@
ARGS=${ARGS// /\~ \~}

node $DIR/../@electron-forge/cli/dist/electron-forge-start --vscode -- \~$ARGS\~

kresli avatar Mar 20 '20 00:03 kresli

I got the same issue on version 6.0.0-beta.52. So how about the following patch to the file electron-forge/packages/api/cli/script/vscode.sh:

#!/usr/bin/env bash
DIR="$( dirname "$( realpath "${BASH_SOURCE[0]}" )" )"

ARGS=$@
ARGS=${ARGS// /\~ \~}

node $DIR/../../../@electron-forge/cli/dist/electron-forge-start --vscode -- \~$ARGS\~

The only thing I try to fix this issue is to get the real path of the script file first, as showed on line 2 in the above code.

thinreyxu avatar Aug 11 '20 13:08 thinreyxu

@thinreyxu that works for me. Thanks!

BillPlunkett avatar Sep 15 '20 23:09 BillPlunkett

This is still an issue as of electron-forge @ 6.0.0-beta.61

Currently, patching this manually. Kinda brutal. Lets fix?

sloan-dog avatar Sep 17 '21 20:09 sloan-dog

@kresli thank you for this patch which worked with electron-forge 6.0.0-beta.61 on macOS with VSCode 1.62.3.

As someone who is new to Electron in general this was a really confusing and unfortunate issue for beginners.

automaton82 avatar Dec 07 '21 03:12 automaton82

What needs to happen to get this solved? A PR?

gbrunow avatar Feb 25 '22 01:02 gbrunow

Yet another workaround or solution for debugging:

In your .vscode/ launch.json

{
    "version": "0.2.0",
    "configurations": [
        { 
            "type": "node",
            "request": "launch",
            "name": "Electron Main",
            "runtimeExecutable": "npm",
            "runtimeArgs": ["run-script", "debug"],
            "cwd": "${workspaceFolder}"
        }
    ]
}

and another script in package.json:

scripts: {
    "debug": "electron-forge start --vscode",
…

(I don't need any extra arguments, so I have not looked into that topic).

jpilgrim avatar Jul 02 '22 15:07 jpilgrim

https://github.com/electron-userland/electron-forge/pull/2908

I'm on 6.0.0-beta.63 and it's still affecting me. I opened the PR with @kresli change. Please help get it through!

wesyao avatar Jul 12 '22 20:07 wesyao

I just ran into this as well. There's a suggestion for a fix further up that works for me.

Change: <project_path>/node_modules/.bin/electron-forge-vscode-nix::7 to be: node $DIR/../@electron-forge/cli/dist/electron-forge-start --vscode -- \~$ARGS\~

It seems like this has been the case for some time. What's in the way of your PR? Seems too simple to let sit like this.

peter-slattery avatar Feb 09 '23 23:02 peter-slattery

I ended up doing this - https://github.com/electron/forge/pull/1370#issuecomment-1474397250

gaziqbal avatar Mar 17 '23 21:03 gaziqbal

I am experiencing this issue and I tried to use the solution from @jpilgrim, since that didn't seem to require direct editing of electron-forge source code.

My project also includes @electron-forge/plugin-webpack, and when I try to debug now (after jpilgrim's changes), I get a different error:

An unhandled rejection has occurred inside Forge:
terminate.js:8
Error: Multiple plugins tried to take control of the start command, please remove one of them
 --> webpack, webpack
terminate.js:8
at PluginInterface.overrideStartLogic (/home/hans/MyApp/node_modules/@electron-forge/core/dist/util/plugin-interface.js:117:19)
    at forgeSpawn (/home/hans/MyApp/node_modules/@electron-forge/core/dist/api/start.js:74:68)
    at forgeSpawnWrapper (/home/hans/MyApp/node_modules/@electron-forge/core/dist/api/start.js:138:31)
    at exports.default (/home/hans/MyApp/node_modules/@electron-forge/core/dist/api/start.js:170:27)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async /home/hans/MyApp/node_modules/@electron-forge/cli/dist/electron-forge-start.js:57:21

Any ideas? I am still very new to electron and have been struggling for months to port our webapp over, dealing with issue after issue. As a new user it is incredibly frustrating and discouraging to never quite know if all the errors you are trying to deal with are because you did something wrong, or if the software is broken.

Please make it so that something as fundamental as debugging is functional for the majority of users!

Edit: I just realized I had some extra changes under forge.config.js that I copy&pasted from some docs to test:

    {
      name: '@electron-forge/plugin-webpack',
      config: {
        // other Webpack plugin config...
        devServer: {
          stats: 'verbose',
        },
        //...
      },
    }

After removing that I'm no longer getting the "multiple plugins" error

thehans avatar Apr 10 '23 18:04 thehans

I'm having this problem as well using electron-forge 6.1.1 with MacOS 12.2.1.

I tried using the original VSCode launch config from the Electron Forge Docs:

{
  "type": "node",
  "request": "launch",
  "name": "Electron Main",
  "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/electron-forge-vscode-nix",
  "windows": {
    "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/electron-forge-vscode-win.cmd"
  },
  // runtimeArgs will be passed directly to your Electron application
  "runtimeArgs": [
    "foo",
    "bar"
  ],
  "cwd": "${workspaceFolder}"
}

I solved it by simply pointing the runtimeExecutable directly at the Bash script's true location rather than the symlink to the same file that exists in .bin/electron-forge-vscode-nix

- "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/electron-forge-vscode-nix",
+ "runtimeExecutable": "${workspaceFolder}/node_modules/@electron-forge/cli/script/vscode.sh",

The problem seems related to the expectation that this line from the script gets the location of th script gets the true location, but instead it gets the location of the symlink.

DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"

frank-weindel avatar May 07 '23 16:05 frank-weindel

Same issue still here with 6.2.1. Either changing ../../.. to just ../ in vscode.sh OR pointing to the .sh file directly as frank-weindel points out fixes this for me.

I came across this old fix as well which seems to have been reverted at some point.

Reimplementing that PR seems to be a good solution. Alternatively, just updating the documentation to include frank-weindel's suggestion might be a good "for now" if there's an edge case keeping the quick fix from getting merged.

jeffbmartinez avatar Jun 17 '23 07:06 jeffbmartinez

Closing with the documentation workaround here. Let me know if there's additional work to be done here.

https://github.com/electron-forge/electron-forge-docs/pull/131

erickzhao avatar Oct 17 '23 23:10 erickzhao