PowerShell for Developers: Command Reference and Automation Recipes

Overview

PowerShell is more useful to developers when commands are organized around problems rather than memorized as an isolated list. The same small set of operations appears repeatedly: locate a configuration file, identify what is listening on a port, inspect a process, test an HTTP endpoint, convert a JSON response into objects, or compare a local environment with a documented setup.

Most examples below work in modern PowerShell and are suitable for Windows development workflows. Some commands also work in Windows PowerShell 5.1, although differences in available commands, JSON behavior, and installed modules are possible. If you are standardizing a new machine, first review the Windows developer environment setup guide.

A useful habit is to test commands with harmless, read-only operations before adding changes such as deleting files, stopping processes, modifying services, or writing configuration. When a command becomes part of a team workflow, put it in a script with clear parameters and error handling instead of relying on a copied one-liner.

What to track

Files, folders, and project state

File discovery is often the first step in debugging a build or deployment issue. These commands help narrow the search without opening multiple tools:

# List PowerShell scripts below the current directory
Get-ChildItem -Path . -Filter *.ps1 -File -Recurse

# Find recently changed JSON files
Get-ChildItem -Path . -Filter *.json -File -Recurse |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 20 FullName, Length, LastWriteTime

# Search file contents for a setting or error message
Select-String -Path .\logs\*.log -Pattern 'timeout|connection refused' -CaseSensitive:$false

Track the locations of project configuration files, generated output, local logs, and scripts that are safe to rerun. Exclude large dependency folders when a recursive search becomes slow. For source control work, pair these checks with Git rather than treating file timestamps as a complete record of project history.

PowerShell, paths, and environment variables

Environment drift is a common source of “works on my machine” problems. Record the values that affect a project, but avoid printing secrets to a shared terminal, transcript, or build log.

# Inspect the PowerShell runtime
$PSVersionTable

# Read a process-level environment variable
$env:NODE_ENV

# List environment variables by name
Get-ChildItem Env: | Sort-Object Name

# Check whether a command is available and where it resolves
Get-Command git, node, npm, dotnet -ErrorAction SilentlyContinue

# Show the current directory and executable search path
Get-Location
$env:PATH -split ';'

For repeatable setup, prefer explicit project documentation or a setup script over manually editing the global PATH. Use Join-Path when constructing paths so scripts remain readable and do not depend on slash conventions:

$projectRoot = Join-Path $HOME 'src\sample-app'
$configPath = Join-Path $projectRoot 'config\local.json'
Test-Path $configPath

Processes and ports

When a local server will not start, check both the process and the port. A port check can tell you that something is listening; process inspection can help identify what it is.

# Find a process by name
Get-Process -Name node, dotnet, python -ErrorAction SilentlyContinue |
  Select-Object Id, ProcessName, CPU, StartTime

# Test whether a TCP endpoint is reachable
Test-NetConnection -ComputerName localhost -Port 3000

# List TCP connections involving a local port
Get-NetTCPConnection -LocalPort 3000 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, State, OwningProcess

# Resolve the owning process ID to a process name
Get-Process -Id 1234

Replace the example port and process ID with values from your project. Treat process termination as a separate, deliberate action; first capture the command line, logs, or process details you need for diagnosis.

HTTP requests and JSON

Invoke-WebRequest is useful when you need response metadata or page content. Invoke-RestMethod is usually more convenient for JSON APIs because it converts JSON responses into PowerShell objects.

# Check an endpoint and inspect the response object
$response = Invoke-WebRequest -Uri 'http://localhost:3000/health'
$response.StatusCode
$response.Headers

# Read a JSON API response as an object
$data = Invoke-RestMethod -Uri 'http://localhost:3000/api/items' -Method Get
$data

# Send a JSON request body
$body = @{ name = 'example'; enabled = $true } | ConvertTo-Json
Invoke-RestMethod `
  -Uri 'http://localhost:3000/api/items' `
  -Method Post `
  -ContentType 'application/json' `
  -Body $body

For local debugging, save a response when you need to compare it later. Use ConvertFrom-Json for a file and ConvertTo-Json to create a readable request or fixture. Be careful with tokens, cookies, authorization headers, and personal data when saving responses.

Logs and repeatable scripts

For a quick log review, combine Get-Content and Select-String. To follow a file as new lines arrive, use -Wait:

# Search a log for several useful patterns
Select-String -Path .\logs\app.log -Pattern 'error','warning','timeout'

# Follow new log lines until interrupted
Get-Content .\logs\app.log -Wait -Tail 50

A small script becomes more reliable when it accepts parameters and stops on unexpected errors:

[CmdletBinding()]
param(
  [string]$Url = 'http://localhost:3000/health'
)

$ErrorActionPreference = 'Stop'

try {
  $result = Invoke-RestMethod -Uri $Url -Method Get
  $result | ConvertTo-Json -Depth 5
}
catch {
  Write-Error "Health check failed: $($_.Exception.Message)"
  exit 1
}

Keep scripts focused. A health check, log collector, and project cleanup task are easier to test and maintain as separate commands than as one large “do everything” script.

Cadence and checkpoints

Use a lightweight review schedule rather than waiting for a failed build to reveal drift.

• Daily or per session: Check the active directory, expected environment variables, local service ports, and relevant logs before investigating application behavior.
• At the start of a project: Record required runtimes, package managers, service URLs, ports, configuration file locations, and commands for starting and testing the project.
• Monthly: Run a small environment audit. Confirm that required commands resolve, stale processes are not holding development ports, and temporary scripts still produce expected output.
• Quarterly: Review reusable scripts, remove obsolete paths and endpoints, test error handling, and confirm that sensitive values are not being printed or committed.
• After a tool or project change: Recheck commands immediately when changing PowerShell versions, runtimes, package managers, API contracts, directory layouts, or local service configuration.

Keep the checklist close to the project README or developer setup notes. The PowerShell developer productivity toolkit can complement this reference when you are collecting reusable commands into a broader workflow.

How to interpret changes

A changed value is a signal, not automatically a fault. A new process on a familiar port may be the expected service after a restart, while a different process may indicate a stale development server or an unrelated application. Compare the process ID, start time, command path, and project state before taking action.

When an HTTP check changes, separate transport problems from application problems. A failed connection can point to a stopped service, incorrect host, or blocked port. A response with an error status means the server responded but did not accept the request as expected. Inspect the URL, method, headers, JSON body, and server logs together.

For JSON, distinguish between invalid syntax and an unexpected schema. ConvertFrom-Json can help prove that a document is parseable, but it does not confirm that required properties have the correct meaning. For API payloads, use a schema validator when the contract matters; see the JSON Schema validator guide for a complementary workflow.

Environment differences deserve the same careful comparison. Check the resolved executable with Get-Command, inspect the relevant variable, and compare the working directory and configuration path. Do not assume that two commands with the same name are the same installation.

When to revisit

Revisit this reference whenever a recurring development task changes or a script stops being predictable. A new repository layout may require updated paths. A changed API may require new headers or JSON properties. A runtime upgrade may alter command availability or output formatting. A team-wide setup change may make an old environment check misleading.

For a practical quarterly review, run through this short sequence:

1. Open a clean PowerShell session and confirm $PSVersionTable and the expected command locations.
2. Run the project’s environment, port, and health checks without modifying files.
3. Review scripts for hard-coded user paths, expired endpoints, unnecessary privileges, and secrets in output.
4. Test one successful case and one failure case for each important HTTP or JSON script.
5. Update the project documentation with the commands that actually worked, then remove obsolete examples.

PowerShell is most valuable when it turns a vague investigation into a repeatable sequence. Keep a small set of read-only checks, promote stable sequences into parameterized scripts, and update them when the surrounding project changes. For adjacent browser-based workflows such as JSON formatting, API inspection, and encoding, use the API request debugging checklist and review data-handling guidance before pasting sensitive values into online tools.