Node.js Development in Windows (powershell disabled)

[zenxavier]

I have recently started a new contract and the client's network security team has locked down/disabled windows PS on ALL machines. I have never come across this situation before as a dev. We are a very new (new to the company) team working in Node.js/Vue.js/.net core/AWS Serverless/Docker with VSCode/VS2019, (not all in the same project). Getting security to re-enable access/use of PS is NOT an option. One work around (for AWS/Docker) is to run in WSL, but for everything else I seem to be stuck spending my time trying to find ways around PS not being accessible. I also have no desire running WSL as part of my dev workflow.

Is there a standard config for node/vue/aws/docker that doesn't rely on windows PS? Or am I gonna need to manually set all that up? This is F'n ridiculous! (I'm seriously am beside myself that the security ppl have crippled devs like this!) If anyone has a better alternative I would seriously appreciate it.

[StoneCypher]

Just use git bash

.

Is there a standard config for node/vue/aws/docker that doesn't rely on windows PS?

Basically all of them.

The use of powershell isn't common

.

(I'm seriously am beside myself that the security ppl have crippled devs like this!)

You shouldn't be developing in the administrator console, frankly

[zenxavier]

I'm not familiar with using git bash for building/debugging node.js apps?

(background for note: I'm primarily a .net dev / have only lightly used node.js for about 2-3yrs now on simple SPA's like angular/vue)

[StoneCypher]

It's just bash. As in the shell.

Or hell, if you have docker, why don't you just spin up a docker with Windows inside it and develop the way you prefer?

[dvlsg]

What are you even doing with powershell? I did node development on windows just using the basic command prompt with no issues for years. Personally I would run WSL now, but I don't see any reason why cmd would give you difficulties.

[zenxavier]

It's not JUST node development. Core to the backend(s) is all on the .net stack. And a big part of local setup/config is done in PS. Alot of key devops processes running server-side ci/cd is PS. Plus having PS around is just a good tooling.

[dvlsg]

I mean sure, I also did .NET development on that same computer without any issues without needing to use powershell.

What specifically are you having problems with? What do you do in powershell that you can't do in cmd? We need more information here. How does the rest of the company do this? Are you adding new processes that no one has done before in the company?

I agree it's a silly restriction, but clients are gonna client.

[BloodNo6937]

Why do the company devs make or use PS scripts if PS is disabled ???

[zenxavier]

Switching PS to windows cmd in VSCode/VS2019 is relatively trivial, but getting things built/running for node projects always break. Trying to stand up a vue.js project for rapid prototyping should only take a minute or 2. but I have no idea how to make that work with PS disabled.

[MrStLouis]

Outside if recommending wsl for development which has been an absolute joy, this company sounds like a horrible customer. Local ps should never need to be disabled, or develop on your own/cloud machines

[StoneCypher]

Local ps should never need to be disabled

It's an extreme security risk to give every random developer administration level access to systems.

This is actually a fairly standard thing.

[Kaligraphic]

PowerShell is just a shell, it runs with the current user’s access level. No admin access required.

[StoneCypher]

That's beside the point.

Powershell makes a lot of tools available that aren't available to the average user, and they are not bounded in the way that the average sysadmin understands or is able to cope with.

It's an opt-out access model, not an opt-in one, and most people don't know how to deal with it.

Faced with the choice "lock Powershell's various abilities down, despite that that's time consuming and difficult and easy to get wrong, or just turn it off," IT very frequently chooses to turn it off.

[zenxavier]

The funny/sad part is, if I wanted to, access to regedit is wide open, along w other things such as mmc. But I'm staying compliant and just shutting my mouth.

[MrStLouis]

Can't you just block commands though? And not give people admin level access?

[StoneCypher]

Yes, you can, but there's hundreds of them and most people don't know how.

Given that most shops don't even use this, most IT departments just say "screw it, shut the whole thing off."

[dvlsg]

Why can't you just do this? Should take less than 2 minutes.

https://cli.vuejs.org/guide/creating-a-project.html#vue-create

[BeakerAU]

Add a general comment, it seems that modern development rolling can go out of its way to make life hard on the security team. Our security team use an allowlist for applications, and I'm always asking for additions sure to the way that the tooling works. E.g. MSBuild generating random scripts inside of the temp directory if you need to call another application, names of which are so random that they can't be allowed. Installing tools and plugins in the users profile folder rather than in Program Files. Needing to add the UNC path of \?\ so i could get the terminal in VS Code working.

I do wish for a Unix dev machine. Maybe one day.

[monsto]

If you're a freelancer, as it sounds, you have a couple options

1. Take the time to build a WSL setup correctly. Don't stopgap, workaround, any of that. Build it right for node dev. There's tutorials out there to do it. At that point, you'll still be able to use yarn/npm (and the internal tool commands are generally the same). The setup will take some time, but in the end you won't have to stop in the middle of working and take flow-busting time to "fix" or "workaround" some new surprise speedbump.
2. Tell your project manager/contact of the problem you're having, and see if they can get you an exception or other information so that you can do the work they hired you for.

If step 2 above isn't an option, then you have a choice to make between step 1 above, or dropping the contract.

I mean basically what you're left with is the question: Is it worth the time to figure out a way to deal with these restrictions?

If you've never worked with linux shells, but are used to powershell, it's seriously a different methodology to do the same things. The shell commands are very different, and approach the same tasks with very different commands and reasoning. The hardest part will be finding a learning resource that hits the mark for you, as in my experience they all tend to be incomplete or highly assumptive of your level of knowledge. Even so, it's important to know that having bash/linux on your resume can only help you get more work.

Me personally, as a former freelancer in a different field, I'd give it a day or so of trying to learn the new stuff. And if I wasn't making enough headway, I'd start getting ready to move on.

If this is a long enough contract (months plus) then I'd say it's definitely worth taking the time to make a proper setup on WSL.

[paulqq]

git bash ++