when running on an env that require namedpipe to avoid exposing NextJs directly (such as IIS or any embed tooling)
this is now impossible to have server.js works

here's a proof with a patched server.js

const path = require('path')

const dir = path.join(__dirname)

process.env.NODE_ENV = 'production'
process.chdir(__dirname)
- const currentPort = parseInt(process.env.PORT, 10) || 3000;
+ console.log(process.env.PORT);
+ const currentPort = process.env.PORT || 3000;
+ console.log(currentPort);

const hostname = process.env.HOSTNAME || '0.0.0.0'

logs:

\\.\pipe\bbe54cb9-3800-4cc8-8c0b-f3eda50b8689
\\.\pipe\bbe54cb9-3800-4cc8-8c0b-f3eda50b8689
  â–² Next.js 14.2.13
  - Local:        http://0.0.0.0:\\.\pipe\bbe54cb9-3800-4cc8-8c0b-f3eda50b8689
  - Network:      http://\\.\pipe\bbe54cb9-3800-4cc8-8c0b-f3eda50b8689:\\.\pipe\bbe54cb9-3800-4cc8-8c0b-f3eda50b8689

 ✓ Starting...
 ✓ Ready in 239ms

BUG:
The actual app will never know that NextJs contains a critical bug changing the server from namedpipe to http / int
the "thing" (IIS etc ...) that started node server.js will continue to think and try to connect to the namedpipe, it will fail app startup / warmup / raise 500.1001 / 500.1002 etc ...

This breaks Azure AppService Windows / IIS on premise / embed tooling running a local nextjs while using namedpipe (that's how docker desktop works with their API for example even though they are running react, their http api uses namedpipe iirc)