Ask HN: Windows Dev Setup? | Hacker News Reader

Ask HN: Windows Dev Setup?

20 pointsiansowinski32 comments

I just landed a job where the only OS to choose from is Windows. As an experienced Linux and macOS user, it sounds challenging, but I see it as an opportunity. Is there anybody with similar experience (web apps development on Windows)? Can you share some bits of advice, tools, and setup?

View on HN

Its better then ever.

1. Use Chocolatey (winget is still new). You can setup everything via it, and I mean everything - node, postgre, docker, vscode, all browsers, selenium and drivers etc.

2. Learn Powershell, but learn it really good. Adopt PowerShell build system Invoke-Build

3. Install better terminal - ConEmu or Windows terminal

4. Enrich Windows using FOSS and cross platform tools: choco install copyq, flameshot, less, fzf, paint.net, git, tortoisegit, winscp, kitty, screentogif, sysinternals, wiztree, gsudo, lockhunter, signal, viber, slack

5. Disable Windows Defender and use some debloater (controversial, but I do it, and system is at least x2-x5 faster). I use https://github.com/W4RH4WK/Debloat-Windows-10 along with ShutUp10 tool.

6. Install the best search engine in the world: cinst everything

Enjoy, its awesome.

Addendum to 2: use PowerShell 7, a newer major version than the one probably coming as default, and based on the modern Core lineage. You get niceties and the sanity you'd expect such as UTF-8 when writing to files with the > operator.

Indeed: cinst pwsh

Also set it as default in terminal/conemu.

BTW, here is my profile.d for PowerShell:

https://github.com/majkinetor/powershell_profile.d

> Disable Windows Defender

And use what instead? Defender is pretty good at keeping you safe, so you definitely need a replacement.

No you don't. You are IT engineer, not a grandma (I guess).

I could be both... ;)

In theory :)

After years of Fedora I now primarily run Windows because WSL just does everything I need. I prefer to still work in WSL Linux env and have my IDEs running through Windows (mostly Visual Studio Code and Goland). It's a nice setup for me because both OSes are just seamlessly available.

Having said that I've had so many sleep/power management problems with Windows with my new ThinkPad that I nearly just switched back to Fedora before finding a configuration that more or less seems to work.

I run Arch Linux in Hyper-V on 11 Pro.

Services (NGINX, MariaDB, PHP/PHP-FPM, etc.) are within Arch.

Project files are in Windows, mounted as an NFS share within Arch.

Editing and committing files mostly from Windows, Atom and git configured for LF.

Executing tasks, Bash scripts and such, from Arch via SSH.

I tend to duplicate tasks in Batch or Powershell for cross-compatibility.

And use the same structure for Electron builds on the Windows side with WIX.

Only complaint is VM performance.

I'll probably swap to a bare-metal Linux machine, using the same approach, soon.

WSL2 with docker containers should bring you quite close to the environment you're used to. Added benefit of working from containers locally is the server parity in OTAP

You can avoid the awfulness of chocolatey by sticking with WSL2. Install that, docker desktop, windows terminal and vscode, voila you are back in linux land and can completely avoid powershell and windows broken file names.

If you avoid PowerShell, go back to where you came from :)

Avoid bad advices.

I realise powershell has fans, but hear me out.

Windows itself has reached a dead end. It is such a mishmash of incompatible tech that Microsoft themselves have stopped trying to fix their admin GUI interface. Between registry, Com and Dcom and even a few leftover text files, there is no way to configure a windows system consistently.

Powershell is an over complicated band-aid to cover it up, ignoring that the wound underneath has become septic.

I get that they had to do something to drag it together, but even good powershell scripts end up as 4 different coding styles crammed together, depending on what component CLI output or interface you are trying to use.

WSL2 is a great thing if you need to do anything with python, node and even .NET. All the online tutorials work and since everything is a CLI these days, why not use a decent shell that doesn't have windows legacy character escape bogosity, broken file names and has sane argument handling?

> Powershell is an over complicated band-aid to cover it up

Sounds like personal preference or non RTFM. Bash is IMO way more complicated, I wouldn't touch it even if my life depended on it. Even authors hate it.

> Windows itself has reached a dead end. It is such a mishmash of incompatible tech that Microsoft themselves have stopped trying to fix their admin GUI interface. Between registry, Com and Dcom and even a few leftover text files, there is no way to configure a windows system consistently.

Yet Linux is not a single system but array of distributions and when you take all into account, you have worst situation then with Windows. Not really comparable IMO.

> WSL2 is a great thing if you need to do anything with python, node and even .NET.

Nah, those work perfectly fine without WSL2. There are things that require it, and that is reason its great (for example Home Assistant).

> why not use a decent shell that doesn't have windows legacy character escape bogosity, broken file names and has sane argument handling?

I use decent terminal - ConEmu. Its like tmux, and better since it allows embedding GUIs in splits rather then just shell. Hard to find better thing on Linux.

I use most powerful shell in existence. I use it cross platform.

> and has sane argument handling?

Are you serious? Bash argument handling must be the worst out there. I might be able to understand other complaints but this one is really lame.

> broken file names

What?

Powershell always feels like writing enterprise editions (like https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...) of simple tasks.

All I'll say is, good luck. I was/am in the same boat and unfortunately for me it'll be the difference between staying in the role and potentially moving on in the future. WSL2 is decent, but there are some fundamental incompatibilities that in some cases make it unusable in a professional context. Everything feels a bit second rate to MacOS/Linux development - tooling, hardware, OS design, peripherals. Ultimately, I'd do almost anything to go back to a Mac and feel like I'm working at 100% efficiency again.

I prefer scoop instead of chocolatey. Also winget just doesn't feel like a finished product.

https://scoop.sh/

Preference has nothing to do with it. We are not in the fashion store.

Scoop is way inferior by number of packages and stability. Mainstream chocolatey packages are embedded which means you don't need network to install them so you can cache them (artifactory, nexus...).

Even for networked packages Chocolatey has its own CDN that keeps them even when vendor removes it (its commercial though).

With scoop, as with brew and winget typically only latest packages work, packages are flaky, and 404 will be your constant friend. Since those package managers do not allow adding binary files they are for causal use, not professional.

I would like to use scoop, but as long as it functions like that, you can't rely on any package working in near future.

I would not use scoop for any sort of build environment.

I have used Chocolatey in the past. I would often run into problems where the commands would leave an application in an inconsistent state - could no longer upgrade, uninstall, or install without some manual intervention. I also ended up having to manually install packages and frameworks because the chocolatey version was way behind the latest version. Basically I always felt like I was fighting against chocolatey rather than it being a tool of convenience.

Maybe it has gotten better in the past few years, but I have completely soured on it by those experiences.

Yeah, it got a lot better in the past few years. It was disaster 5+ years ago, as NO package was embedded and there were number of badly designed components such as package parameter parsing. Even now its far from perfect but its better then anything else on Windows.

I don't work for Chocolatey but I am active as community maintainer. I also created AU - framework for automatic updates - which is used on largest community repository. You can see its multiple-per-day output here:

https://gist.github.com/choco-bot/a14b1e5bfaf70839b338eb1ab7...

All the packages marked with download icon are embedded, they contain the software and will work forever. AU also has plugin that publishes them on Github releases also, so even if Chocolatey goes down or not exists any more you will be still able to use them.

Quality of packages there is great, and there are more and more package maintainers that use the guidelines provided.

On the negative side, Chocolatey team behaves toward community repository like it is freak accident of nature rather then major and most important component of the product.

WSL2 all the way. I didn't like Chocolatey.

Just make sure that your actual code/project files are also inside of your WSL (https://dev.to/ajeet/so-you-have-installed-windows-subsystem...)

There's a thing called WSL Bridge that VS Code hooks into, or uses somehow in order to run VS Code in Windows, but it is accessing and running code that's inside the WSL.

I used various terminal programs but the most recent one I used was Windows Terminal: https://www.microsoft.com/en-us/p/windows-terminal/9n0dx20hk...

This alleviated many issues I had and I ended up getting my whole team onboard with the same setup.

We were running Angular apps, and also vanilla JS stuff with Bootstrap, Gulp, Webpack, Live Server.

I think the best solution is to ask your coworkers how they provision their dev environments, because windows dev is such shit that you don't want to struggle to build and run other peoples' code in the office.

If you can build/run code in a linux environment:

wsl2 gives you linux vm running in hyper-v alongside windows.. the vm pretty much has direct hardware access and is fast. From here, you can install linux based git, rsync, etc ... and the vm has full access to the windows filesystem.

vscode has a nice wsl extension which runs in client/server mode with server living in the linux vm and client on windows.

wsltty is closest feeling simple terminal, with translucency, etc.

... with this setup, i got rid of cygwin, vagrant, virtualbox, etc.

Visual Studio Professional, Eclipse/Netbeans, VS Code.

latest PowerShell, Windows Terminal, WinMerge, Notepad++, ToirtoiseGit/SVN, Paint.NET.

Office, FF, Chrome, EdgeChrome.

Everything else is project specific.

I'd say much of that is likewise project specific. .NET teams do tend to solidify on a set of tools like you listed, but such lists are shared tooling agreed upon by the team, not a requirements list for everyone who will work on a Windows box.

A simple tip: with WSL/WSL2, you can run XServer process in Windows and your IDE launched inside WSL will show up as just another window in your Windows task bar (you have to point it at the Xserver). It completely eliminates the annoying double desktop/double taskbar setup that's normally a drawback of using a VM.

Powershell, Windows Terminal and oh-my-posh get you pretty close to zsh on Linux. I'll comment back with a few more tweaks I had to make to powershell to get closest to the Linux experience.

But my biggest gripe is not having tmux. There are some window/tab/pane management shortcuts in Windows Terminal but they're not as good as tmux (yet).

Here's my $PROFILE:

    Import-Module PSReadLine
    Set-PSReadLineOption -EditMode Emacs
    Set-PSReadLineOption -HistorySearchCursorMovesToEnd
    Set-PSReadLineKeyHandler -Key UpArrow -Function HistorySearchBackward
    Set-PSReadLineKeyHandler -Key DownArrow -Function HistorySearchForward
    Set-PSReadLineKeyHandler -Key Tab -Function Complete

    Import-Module posh-git
    Import-Module oh-my-posh
    Set-PoshPrompt -Theme material

    function e { emacs -nw $args }
    function gs { git status $args }
    del alias:gc -Force
    function gc { git commit $args }
    del alias:gp -Force
    function gp { git push -u origin $(git branch --show-current) }
    function python { python3 $args }

You can also enable predictive intellisense with PSReadLine 2.1+

https://devblogs.microsoft.com/powershell/announcing-psreadl...

winget is your friend, though you will find yourself living between Windows PowerShell and Git Bash most of the time.

Git bash and you're done

Reply on news.ycombinator.com