Feature Request: determine node version to use for a project from .nvmrc

[kvernon]

I want to understand the Node.js {SYSTEM DEFAULT} Setting better

Currently, on windows, I am running a non-wsl setup. Also, I use nvs (similar to nvm).

When I start a new project, Webstorm understands that I'm referencing node 14 via .nvmrc and 14, however, it seems that WallabyJS doesn't seem to acknowledge it.

So I went here hoping for more info, https://wallabyjs.com/docs/intro/get-started-jetbrains.html, however, I don't seem to find anything over it. I was hoping to learn generalizations plus some maybe additional magic setting with this too.

Message:

Wallaby Notification: Can not start node.js process (node), make sure your system has node.js installed.

I guess from this my other question is: Should Wallaby.js be able to learn of configs from JetBrains Idea-based IDEs? It seems odd to have to do it twice, once for the ide and once for Wallaby.js

recap:

1. Do you all have docs (or anywhere else) over details for nodejs config setting?
2. I feel like WallabJS should be able to tap into the IDE's setting for nodejs, why isn't it, and if it's a feature request could we have it? :)

Above all, thanks for this amazing tool, Kelly

[smcenlly]

The {SYSTEM DEFAULT} is the version of node that is resolved from your PATH variables in your operating system. If you don't have node in your path or need to use a different version, then you may specify the path in this field.

We'll convert this issue to a feature request.

[whjvenyl]

I ran into a similar problem, not being able to start Wallaby.js from IntelliJ. Using nvm to manage my node installations, doing a echo $PATH did show that the node binary was available on a terminal session: /Users/username/.nvm/versions/node/v14.17.3/bin:/User/username/...

What was missing though is a symlink to /usr/local/bin/node After doing ln -s "$(which node)" /usr/local/bin/node Wallaby.js started working.

I'd rather not having to symlink the binary though since it breaks switching node versions.

So to clarify on the answer by @smcenlly: NO, the {SYSTEM DEFAULT} does NOT resolve the node version from the PATH or else the functionality is broken

[smcenlly]

@whjvenyl - what operating system are you using?

NO, the {SYSTEM DEFAULT} does NOT resolve the node version from the PATH or else the functionality is broken

This very much depends on how your path variable is configured. If your path is being set from your shell script, then it won't be picked up when Wallaby runs because Wallaby does not run your shell script on start up. On my computer (MacOS) I use nvm and didn't need to do anything special.

You can see how your PATH is set from a Wallaby context with this: console.log(process.env.PATH).

You may refer to your operating system specific instructions for how to set system path (outside of any shell scripts).

[whjvenyl]

same or similar setup on my end: macos big sur with nvm

[IPWright83]

I'm having this issue too, I've got /Users/ian/.nvm/versions/node/v20.11.1/bin in my $PATH from the terminal and I've tested using console.log(process.env.PATH) which also includes it. But Wallaby refuses to run because it can't find Node.

Most other tools I use have extension settings, but I can't find any documentation for any in Wallaby. Here's an example of a similar tool, where if we could apply this it'd make life a lot easier.

  "linters": {
        "eslint": {
            "env": {
                "PATH": "/Users/ian/.nvm/versions/node/v20.11.1/bin"
            },
            "executable": "/Users/ian/.nvm/versions/node/v20.11.1/lib/node_modules/eslint_d/bin/eslint_d.js"
        }
    }

[ArtemGovorov]

@IPWright83 Please check this docs section:

you may use node_path setting in your User/Wallaby.sublime-settings file to specify the full path to node.js executable file.

{
"node_path": "your/nodejs/path/node"
}

[IPWright83]

Thanks @ArtemGovorov! Sorry I'd missed that in the docs, and searching hadn't helped (might be worth a link from the FAQ's).

Also as a general aside (at least for Sublime) most extensions offer a side by side view when changing settings and have the default values set/documented, make it super easy to find :) This sort of thing would be a big improvement in discoverability.

[ArtemGovorov]

@IPWright83 Thanks for your feedback. We have a close plan to re-work our docs, and we'll address the discoverability concern for this type of issues as a part of it.