[hackujin]

That is not a solution. I want to work on files in my WSL home folder. Lots of language based package managers like npm and composer "live" inside a folder in your home directory. It's very important that VSCode running as a windows application be able to read/write to these files.

As it is right now I can't even edit my ~/.ssh/config from VSCode without jumping through hoops.

[ewzimm]

If you want to access your home folder in both, all you have to do is first create the folder in Windows, for example, create a wslhome folder inside your user folder in windows. Copy everything in your current WSL home folder, including hidden files, into that one. Then rename your WSL home folder to back it up and replace it with a symbolic link to the Windows folder. In WSL, use ln -s /mnt/c/Users/[your Windows user name]/wslhome /home/[your wsl user name]. The real folder exists in Windows and is usable in either environment.

[arbie]

This is exactly right. Having interop is great.

[BinaryIdiot]

> I want to work on files in my WSL home folder. Lots of language based package managers like npm and composer "live" inside a folder in your home directory. It's very important that VSCode running as a windows application be able to read/write to these files.

No. You don't want this. Linux and Windows are different platforms; if your Windows application could use your packages installed through Linux (and vice versa) then none of the native modules would work without a reinstall.

The side effects suck and they can make it better IMO but not sharing dependencies isn't an issue at all IMO.

> As it is right now I can't even edit my ~/.ssh/config from VSCode without jumping through hoops.

Yeah that sucks though for some things like git bash, etc, they use the proper windows home directory. So I end up just keeping those there and straight up copying or aliasing them to the WSL home folder.

It's not a great experience but it works.

[hackujin]

Of course I want this!

Globally installed npm and composer packages live in ~/.npm/ and ~/.composer/ and they both have a global packages.json esque file that I need to occasionally edit. The packages installed in those folders MUST be parsed by VSCode for intelesense to work properly.

All I'm saying is I'm not gonna jump through all these hoops. I'd rather just keep working on my mac.

Hell I'd rather hackintosh a surface pro rather than deal with these issues.

Running VSCode through X is annoying.

[ivan_gammel]

npm/node works fine in Windows (and I'm pretty sure it's the same with composer), so why do you want to use it in WSL?

Edit: this is a genuine question of an engineer, who uses Git/npm/node for fullstack development on Windows 10 every day. What kind of setup do you have and what UX do you expect, that requires running the tools in WSL?

[hackujin]

I just don't want to use Windows to test my code when production is in Linux. There are things all those tools do when running in Windows that is specific to Windows. And I'm not some anti-windows Microsoft hating guy. My main desktop is running Windows 10 and I was quite excited for WSL to come out so I had Windows 10 Insider Preview running on my machine for more than a year. But at the end of the day when I want to do "real" work I keep going back to my Macbook.

Windows command prompt compared to bash is simply horrible. I personally find Powershell to be just as bad. The console app in windows is still light years behind Terminal in OS X. In fact VSCode's built in terminal wrapper is orders of magnitude better.

Things like wkhtmltopdf to generate PDFs or ffmpeg to work with videos should run as they do in Linux on the production server. In OS X I can use brew to set things up. In windows I have to hunt down binaries, put them in the right place, and set the path manually via an OS level GUI many clicks down in Advanced Settings.

The extra work I need to do to make all those tools work in windows makes setting up a windows dev environment cumbersome and annoying. The way it's laid out in OS X gives me way cleaner interoperability with the way the code actually runs in a Linux environment.

It's one of the reasons I love WSL! Finally I can have a ~/.ssh/config in Windows! But I still can't edit the file from a Windows text editor.

Finally if I'm on a team where the production environment relies on some of these linux binaries being available I don't want to waste work hours researching and writing on boarding documentation for the one dev that feels like working in windows when the rest of us are on macs.

[dbetteridge]

C:\Users\Windows Username\AppData\Local\lxss\home\WSL username\.ssh ?

Unless i'm misunderstanding the issue

[freeone3000]

Stuff in lxss is treated "special" - files in that directory have unix numeric permissions on NTFS instead of ACL permissions. Windows doesn't know how to set those, so if win32 subsystem is updating permissions (for instance, on file save) and the linux subsystem is updating metadata (for instance, on file save), it's possible to end up in a state where neither subsystem is able to get permission to touch the file again.

For this reason, it is recommended to only edit files outside this directory from both subsystems (not to say this isn't issue-free, but it's relatively reliable.)

[hackujin]

The file becomes invisible to WSL right after it gets edited in Windows. It's because it's doing weird tricks to associate UNIX permissions to files stored in Windows. The Windows app will break those permissions so instead of mitigating that in WSL it simply stops being able to "see" the file.

[voltagex_]

Would drvfs and symlinks solve your issue with ssh and npm?

[baq]

I'd install vscode in wsl and run it through a Windows X server.