Open kvernon opened 3 years ago
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.
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
@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).
same or similar setup on my end: macos big sur with nvm
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"
}
}
@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" }
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.
@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.
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:
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:
Above all, thanks for this amazing tool, Kelly