fix: DAH-0000 enable local dev on Windows

[fwextensions]

Description

Four small changes that let the app run for local development on Windows. No application code is touched, and nothing here changes behavior on macOS or Linux.

Jira ticket

DAH-000 — developer environment setup, no ticket.

The changes

• package.json — run bin/shakapacker-dev-server through ruby explicitly. Windows cmd.exe can't execute a Ruby shebang script directly.
• Gemfile — uncomment tzinfo-data for the Windows platforms. Windows ships no system zoneinfo database, and the gem is already platform-gated, so it isn't installed anywhere else.
• config/shakapacker.yml — pin dev_server.static.publicPath to /packs/ in the development block. Shakapacker's webpackDevServerConfig.js assigns the absolute filesystem output path there rather than a URL path; on Windows the backslashes break path-to-regexp when webpack-dev-server registers it as an Express route (Missing parameter name at index 2).
• config/database.yml — treat PUMA_WORKERS=0 as one process when sizing the connection pool. Puma's clustered mode isn't supported on Windows, so single mode is set with PUMA_WORKERS=0, which meant a pool of 0 * threads = 0.
• .env.sample — document the PUMA_WORKERS=0 workaround, commented out.

Risk

The database.yml change is the only one that isn't Windows- or development-scoped, so it's the one worth a careful look. It computes max(PUMA_WORKERS, 1) * PUMA_THREADS instead of PUMA_WORKERS * PUMA_THREADS, which is identical for every value of 1 or higher — it only differs when the variable is explicitly set to 0, where the old expression produced a pool of zero connections. The default of 2 is unaffected.

The shakapacker override is inside the development: block only. The tzinfo-data gem is gated to mingw/mswin/x64_mingw/jruby platforms and does not install on macOS or Linux; Gemfile.lock gains the platform-specific entries.

Review instructions

Applies to local development only; nothing to check in a deployed environment.

• On macOS or Linux: bundle install && npm start should behave exactly as before. That is the real test here — that this is a no-op off Windows.
• On Windows: with PUMA_WORKERS=0 set in .env, npm start should boot both the Rails server and the webpack dev server, and the app should load.

Verified on Windows 11 (the branch is what this environment is currently running on) and on macOS, where the app runs exactly as before — the no-op-off-Windows claim is confirmed, not assumed. Not verified on Linux.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Enables local development on Windows by adjusting startup scripts and development configuration to account for Windows execution and path semantics, while aiming to keep behavior unchanged on macOS/Linux.

Changes:

• Run bin/shakapacker-dev-server via ruby in package.json to avoid Windows shebang execution limitations.
• Add tzinfo-data for Windows Ruby platforms (and lock the added Windows platforms/gems in Gemfile.lock).
• Apply Windows/dev-only Shakapacker dev-server static.publicPath workaround and prevent a zero-size DB pool when PUMA_WORKERS=0.

Reviewed changes

Copilot reviewed 4 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
package.json	Executes the Shakapacker dev server script through ruby for Windows compatibility.
Gemfile	Enables tzinfo-data only on Windows/JRuby platforms to provide zoneinfo data.
Gemfile.lock	Captures Windows platform additions and the tzinfo-data dependency in the lockfile.
config/shakapacker.yml	Pins dev_server.static.publicPath in development to a URL path to avoid Windows backslash route issues.
config/database.yml	Treats PUMA_WORKERS=0 as a single process to avoid a connection pool of zero.
.env.sample	Documents the Windows PUMA_WORKERS=0 local-dev workaround.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.