Allow standalone output server.js port to be non-numeric

[myronng]

Describe the feature you'd like to request

When using output: "standalone" in next.config.js, a server.js file is automatically generated. The server.js assumes that the port can only be numeric via the following line:
const currentPort = parseInt(process.env.PORT, 10) || 3000

However, when using iisnode to host a Next.js application in Windows Server, process.env.PORT is a named pipe (a string). This causes problems where starting the Next server will default to port 3000 instead of using the port provided by iisnode. I'm requesting to allow currentPort to be a string.

There have been other libraries that have run into the same problem:
graphql-hive/graphql-yoga#232

I'm also willing to open a PR if needed - just let me know!

Describe the solution you'd like

Instead of generating server.js with
const currentPort = parseInt(process.env.PORT, 10) || 3000
use
const currentPort = process.env.PORT || 3000

From my tests, changing that line allows iisnode to host the application properly.

Describe alternatives you've considered

I've considered using a custom server to deploy with iisnode but I'd prefer to keep using features like automatic static optimization. I also thought of not including .next/standalone/server.js in every deploy and keeping a single copy of server.js from a previous build. However, I wasn't sure how often the output of server.js would be changing and would prefer not to constantly check a diff between the newly generated one and the existing one.

[myronng]

This does appear to happen in canary as well.

    Operating System:
      Platform: win32
      Arch: x64
      Version: Windows 10 Pro
    Binaries:
      Node: 16.13.0
      npm: N/A
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 12.2.1-canary.3
      eslint-config-next: 12.2.0
      react: 18.2.0
      react-dom: 18.2.0

[myronng]

Looks like there's at least one person facing a similar problem, but it differs slightly in that they weren't using the output: "standalone" configuration in #22922. Any chance this could get looked into?

[tiagojsrios]

I would like to see the original issue open again. This is definitely a problem when you want to host next.js on Azure App Services that run Windows.

I solved the issue by replacing the line during the build time, as you can see below:

- script: sed -i 's/&& parseInt(process.env.PORT) //' ./node_modules/next/dist/cli/next-start.js

However, this is a dirty hack and named pipes should be natively supported by next.js in my opinion.

[botsvik]

Hey, I did the same and it seems to be fine as far as JS goes. Only thing now my IIS sends me to https://example.com/pipe/xxx-xx/pipe/xxx-xxx/pipe/xxx.... did you have similar issue? Can you share your web.config. I think there maybe issue with my setup but I'm not sure 😕

[myronng]

@botsvik It seems to be a problem with Next.js version 13.4 and higher. The standalone output was changed and now the node server is created in a way that doesn't play nice with iisnode. I didn't end up finding any solution that wouldn't require forking Next.js.

[botsvik]

@myronng Thanks, I was able to convince my team to move off of windows azure web app service to linux one. No more iisnode.

[uguremirmustafa]

All windows servers should be demolished

[tebeco]

@uguremirmustafa
that isn't related to Windows, it's visible on windows because it's using namedpipe in conjunction to iisnode as a handler, you couldn't have guessed that without knowing, so i understand it's easy to blame on windows i guess ;)

parseInt() here break all scenario running on namepipe regardless of the OS

[uguremirmustafa]

Thanks @tiagojsrios, removing parseInt solved my issue also.

[pksorensen]

Ran into this also, and is going to quick hack fix by remove parseint also. Would love to seen this supported / fixed, as it consumed a hole day of work figuring out what the issue was