While it will be nice when the dev command prompt supports Powershell as well part of the issue is which PS version to support. PS 5 is on all Windows machines but it is old and PS 7.1 is preferable. But some of the behavior is different so MS would need to create a script for either version which adds more effort.
However you can still call the existing dev command prompt from PS. That is what I do myself. I have my own "Dev command prompt" which is Powershell. Amongst other things like setting up my custom path variables it calls into the VS command prompt to initialize it as well. Therefore I have all the features of the command line shell plus my own customizations.
Here's the subset of the PS that I use to set up my environment.
function InvokeCommandFile
{
param(
[Parameter(Mandatory=$true)][string] $filePath,
[string] $arguments
)
$tempFile = [IO.Path]::GetTempFileName()
## Store the output of cmd.exe. We also ask cmd.exe to output
## the environment table after the batch file completes
cmd /c " `"$filePath`" $arguments && set > `"$tempFile`" "
## Go through the environment variables in the temp file.
## For each of them, set the variable in our local environment.
Get-Content $tempFile | Foreach-Object {
if($_ -match "^(.*?)=(.*)$")
{
Set-Content "env:\$($matches[1])" $matches[2]
}
}
Remove-Item $tempFile
}
# Call the VS command prompt script
$env:VSTOOLS='C:\<path to VS>\Common7\Tools'
InvokeCommandFile "$env:VSTOOLS\VSDevCmd.bat"
The path to VS depends upon where you install it so you'll need to adjust. The batch script that MS runs mostly sets up envvars but since that is being run in a separate session we have to hoist the variables into PS. There may be an easier way to do this in newer PS versions but the version I use (copied from somebody else) for both PS 5 and 7.1 outputs the script results to a temp file and then finds the env variables and sets them in the current PS session. I've been using this for years without issues but there could be an oddball case it doesn't work for.