cannot set node_module path for visual studio code - visual-studio-code

VSCode Version: 1.3.1
OS Version: OSX 10.11.6
Steps to Reproduce:
I use this script to lazy load nvm/node/npm for zsh. http://broken-by.me/lazy-load-nvm/
When I start vscode, it cannot find the library eslint, although it is installed already. Without lazy-load-nvm script, I do not have such a problem.
How can I fix vscode to search in the right path?

Related

VS code markdown text wrapping issue

I am using using visual studio code on arch linux, with official compiled version download from arch linux aur source (https://aur.archlinux.org/packages/visual-studio-code-bin). However, I found that the text wrapping in markdown mode does not work well.
The under screenshot was taken from my linux desktop computer.
Linux Screenshot
As we can see that, in the last 2 line, part of words are hidden due to incorrect word wrapping.
This screenshot is taken from my windows desktop, which is what I want to have on linux desktop.
Windows Screenshot
Background information related to my Linux desktop:
System: Archlinux
System version: all of software are updated to latest version
VS Code Version: 1.75.1-1
Windows Manager: awesome wm(with Xorg)
What I have tried:
reinstall vs code, and removing all of add-on/extensions installed, does't work.
try to use code-oss, which is compiled by arch linux community, does't work.
clean all of user settings, does't work.

Libraries available to wsl not to vscode on windows

So I was doing gpu programming using cuda and had installed the same for my wsl on windows. So the code I wrote works on wsl, printing the correct output. But the libraries such as bits/stdc++.h and sys/time.h cant be found by vscode. Why doesnt my wsl not produce any errors and how to correct this?
compiling on wsl using nvcc
libraries cant be found
So I am thinking of adding the requierd libraries to micrososft visual studio folder in program files. But I am unable to get the files for sys/time.h. Did I do some error while installing the libraries? I have Microsoft visual studio version 2022.

does mingw-w64 work in vscode for Mac m1?

I installed mingw-w64 using homebrew on my Mac m1 and then in vscode I installed the code runner extension as the tutorial said but it doesn't run my code after I press the command "cmd+opt+n" , nth seems to work.

Not able to open VS Code from Terminal in my MacBook BigSur11.3.1

Good day community. I have installed VS Code in my MacBook Air M1 chip running on BigSur 11.3.1 but whenever I set the code command in PATH (using Command+Shift+P) it only appears to be working for current session and doesn't work if I restart VSCode. I have to set the code command in PATH again. Please help me in configuring code command permanently so that i can open VSCode from any directory whenever I want. Thanks
I think I have got the solution. After installing VSCode in your Mac (which will be in download folder) move VS Studio Code.app file to Application Folder and then again install the code command in PATH from VSCode(using Command+Shift+P) and thats it.

VSCode constantly asks me to Restore

VSCode 1.20.0 on Windows 10, with C# extension ms-vscode.csharp 1.14.0.
VSCode Terminal points to bash (Windows Subsystem for Linux)
VSCode is opened on a folder containing a .NET CORE 2.0 C# project
Everything is fine, intellisense works, project references are understood.
Whenever I switch focus to the VS Code terminal and type "dotnet build" or "dotnet test", VSCode gets confused. Red Squigglies underline every line of source code, intellisense stops working, and VSCode opens two info boxes that say
Info: There are unresolved dependencies from src\Project.csproj. Please execute the restore command to continue.
Info: There are unresolved dependencies from test\Project.Tests.csproj. Please execute the restore command to continue.
When I click the "Restore" button inside the info box, about 15 seconds later the project works again. But why, this happens all the time, I tend to dotnet build frequently. Can I configure VS Code differently to avoid this problem? It doesn't seem right that building code would break the editor functionality so I must be doing something wrong.
EDIT:
This problem seems to repro only if I dotnet build or dotnet test in WSL\bash (whether Internal or External Terminal). It doesn't seem to repro when I build or test in an external cmd.exe
EDIT:
cmd.exe dotnet --info
.NET Command Line Tools (2.1.4)
Product Information:
Version: 2.1.4
Commit SHA-1 hash: 5e8add2190
Runtime Environment:
OS Name: Windows
OS Version: 10.0.16299
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.1.4\
Microsoft .NET Core Shared Framework Host
Version : 2.0.5
Build : 17373eb129b3b05aa18ece963f8795d65ef8ea54
WSL\bash $ dotnet --info
.NET Command Line Tools (2.0.3)
Product Information:
Version: 2.0.3
Commit SHA-1 hash: eb1d5ee318
Runtime Environment:
OS Name: ubuntu
OS Version: 16.04
OS Platform: Linux
RID: ubuntu.16.04-x64
Base Path: /usr/share/dotnet/sdk/2.0.3/
Microsoft .NET Core Shared Framework Host
Version : 2.0.3
Build : a9190d4a75f4a982ae4b4fa8d1a24526566c69df
The reason this might be happening could be because VS Code is using Omnisharp running on Windows - when you build using Bash, you are building for linux, and therefore all the reference paths generated in files in the obj folder will be linux paths, not Windows paths.
When Omnisharp looks for the referenced dependencies for intellisense in VS Code, it can't find them, and so VS Code requests you to restore your project.
You could confirm by checking any of the files in the obj folder, and looking at the paths.
EDIT - 2019
Just an update on this - things are looking promising. We will soon be able to use the VS Code Remote Extension Pack to run extensions INSIDE the WSL environment (or Docker Containers or even over SSH sessions). This is pretty awesome - it should mean that not only does our code run in WSL, but the extensions will also - and therefore OmniSharp extension will be running in WSL, using the Linux binaries for intellisense etc.
I am personally pretty excited by the new tools Microsoft is releasing. Its a really god time to be developing on the Windows platform with tools like WSL, VS Code, Docker and Hyper V... and the upcoming WSL 2 is going to be incredible (FULL Linux Kernal baked into Windows!!!)