Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Can't launch Playwright VSCode extension due to "spawn node ENOENT" #33996

Closed
CHC383 opened this issue Dec 13, 2024 · 5 comments · Fixed by microsoft/playwright-vscode#573

Comments

@CHC383
Copy link

CHC383 commented Dec 13, 2024

Version

1.49.1

Steps to reproduce

This is a bug report for the Playwright VSCode extension, I am not sure about how to reproduce as it is more like an environment related issue rather than code related, will just try to summarize the current findings and investigations.

The whole story begins after I installed the plugin, and I don't see anything listed under projects as shown in the Playwright doc, and I only see tests from the Vitest VSCode extension. Then I clicked Refresh Tests, and got an error message "Please install Playwright Test via running npm i --save-dev @playwright/test", which leads me to #28703 and feels like my issue might be related to Node path.

  • I toggle the Developer Tool and got the following error message, which says nothing about Node path but looks like it is trying to load the Node path

    Error
    [Extension Host] [Playwright Test]: spawn node () {
    for func in _omz_nvm_load nvm node npm npx pnpm pnpx yarn corepack
    do
        if (( $+functions[$func] ))
        then
            unfunction $func
        fi
    done
    [[ -f "$NVM_DIR/nvm.sh" ]] && source "$NVM_DIR/nvm.sh"
    _omz_nvm_setup_completion
    _omz_nvm_setup_autoload
    if [[ "$0" != _omz_nvm_load ]]
    then
        "$0" "$@"
    fi
    } ENOENT
    
  • It is similar to another issue I ran into on Vitest extension recently, which I resolved by setting its shellType to terminal. And this makes me feel that:

    • This might an issue on the VSCode extension framework for loading Node rather than on a specific extension, as both extensions runs into the same error
    • This might be very specific to my environment setup
  • I also tried to launch the VSCode from the terminal code . to see if it sets path properly and fixed the issue, but unfortunately it doesn't help.

Basically I am running out of idea on debugging this, so any help would be appreciated.

Expected behavior

Playwright extension launch successfully

Actual behavior

Getting message "Please install Playwright Test via running npm i --save-dev @playwright/test" after clicking Refresh Tests in the Testing tab.

Additional context

No response

Environment

System:
    OS: macOS 15.1.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 274.95 MB / 16.00 GB
  Binaries:
    Node: 22.11.0 - ~/.nvm/versions/node/v22.11.0/bin/node
    npm: 10.9.1 - ~/.nvm/versions/node/v22.11.0/bin/npm
    pnpm: 9.15.0 - ~/.nvm/versions/node/v22.11.0/bin/pnpm
    bun: 1.1.38 - ~/.bun/bin/bun
  IDEs:
    VSCode: 1.96.0 - /usr/local/bin/code
  Languages:
    Bash: 3.2.57 - /bin/bash
  npmPackages:
    @playwright/test: ^1.49.1 => 1.49.1

Additional:
Playwright plugin version: 1.1.12
Shell: zsh 5.9
Shell plugin framework: Oh My Zsh
NVM version: 0.40.1
@yury-s
Copy link
Member

yury-s commented Dec 13, 2024

It seems that something messed up the path to node under vscode. One thing might be causing it is https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/nvm plugin that you use with "Oh My Zsh", can you try to disable it and run again?

The code that searches for Node to run in the VSCode extension is here: https://github.com/microsoft/playwright-vscode/blob/6c301656dab9f7b4a167a29056a91f4a7279855c/src/utils.ts#L95 and our hunch is that it fails at some step. If you are comfortable with VSCode extension framework, you can try debugging that function:

git clone https://github.com/microsoft/playwright-vscode/
cd playwright-vscode
npm i && npm run watch
# open VSCode and run launch there

@CHC383
Copy link
Author

CHC383 commented Dec 13, 2024

@yury-s Thanks for the quick response and the insights, disable the nvm plugin leads to node not found, looks like the logic to search for Node doesn't work for my setup, I will try to debug there.

In the meantime, the problematic code comes from the lazy startup in the nvm plugin, and turning that off, i.e. enable eager loading, solves the problem.

BTW could you elaborate # open VSCode and run launch there, I am not familiar with the extension framework but interested in learning more, just not sure about how to hook the local extension after running npm run watch, is it the steps here? NVM I figured that out, open playwright-vscode in VSCode, press F5 to enter extension host and in the launched VSCode window, open my project.

@yury-s
Copy link
Member

yury-s commented Dec 13, 2024

In the meantime, the problematic code comes from the lazy startup in the nvm plugin, and turning that off, i.e. enable eager loading, solves the problem.

Thanks for sharing, this is very helpful. I'm not sure if we are going to address it in the node search logic, given that it is specific to a particular mode of a peculiar shell setup, but having it documented here may help others.

@CHC383
Copy link
Author

CHC383 commented Dec 13, 2024

Okay here is a more in depth analysis:

  • When the OMZ nvm plugin is in used, users don't need to manually source nvm, i.e. [ -s "$NVM_DIR/nvm.sh" ] && source "$NVM_DIR/nvm.sh" or [ -s "$HOMEBREW_PREFIX/opt/nvm/nvm.sh" ] && source "$HOMEBREW_PREFIX/opt/nvm/nvm.sh (Homebrew installation). That's why disabling the nvm plugin doesn't work for me at the beginning (I didn't source nvm by myself), and a proper nvm setup (see caveats below) should work with the Node search/detection logic, which runs which node through your shell behind the scene.
  • Now let's put the OMZ nvm plugin aside for a moment, for a pure nvm setup:
    • If you want Node to always be loaded and work with which node any time, a default alias needs to be set, i.e. nvm alias default node
    • Otherwise, Node won't be loaded unless you have .nvmrc in your project, and someone needs to run nvm use to activate it. In this case, nvm default alias can be omitted
      • If you open the terminal on the project directly, NVM (source nvm.sh) will activate it. And because of that, VSCode use case will activate it, as it runs the terminal on the project path
  • Other than the cases listed above, .nvmrc won't be auto loaded, that's how the OMZ nvm plugin comes into play.
    • With nvm plugin works in eager loading mode, Node will be loaded when the shell starts, thus which node works and the extension could detect the Node version successfully
    • With nvm plugin works in lazy loading mode, node (and some other commands) is replaced with a lazy loading function to load NVM when those commands are invoked, thus which node returns the definition of the function instead of a path to Node, and cause the extension to crash.

In summary, the extension works fine if

  • Node is installed through non-nvm and can be found in PATH
  • Node is installed through nvm, and nvm default alias is set, or .nvmrc is presented in the project
  • Node is installed through nvm, and OMZ nvm plugin is used with eager loading mode

At this point, I agree with @yury-s that the lazy loading case (which node returns a function) is too specific, and I am not sure how to elegantly solve that. Maybe running node --version before which node, which should conceptually work for any lazy loading case, is a potential solution. @yury-s please let me know if you think this proposal worths a PR, and I am happy to contribute, otherwise please feel free to close the issue and I can live with other workarounds mentioned above.

@yury-s
Copy link
Member

yury-s commented Dec 14, 2024

Very nice write-up, thank you! I think we can modify the logic of finding the node to handle the case of lazy loading. As an optimization we could run node --version only if type node says node is a function. Feel free to send a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants