Blitz: Support custom port + friendly help if port already in use

Created on 27 Apr 2020  Â·  13Comments  Â·  Source: blitz-js/blitz

What is the problem?

Starting blitz app with command blitz start, and if default port which is 3000 and that port is used by example by an app in react dont change the port

Steps to Reproduce:


    1. start react app


    1. start blitz app

Versions:

[Add the output of `blitz --version --verbose` here]
➜  myapp git:(master) blitz --version --verbose
You are using alpha software - if you have any problems, please open an issue here:
  https://github.com/blitz-js/blitz/issues/new/choose

debug: local
debug: pkgPath: C:\Users\alvar\react\myapp\node_modules\@blitzjs\cli

Windows 10 | win32-x64 | Node: v13.13.0

blitz: 0.7.0 (global)
blitz: 0.7.0 (local)

Supporting Documentation

Please include applicable logs and screenshots that show your problem.

➜  myapp git:(master) blitz start
You are using alpha software - if you have any problems, please open an issue here:
  https://github.com/blitz-js/blitz/issues/new/choose

√ Prepped for launch
[ wait ]  starting the development server ...
[ info ]  waiting on http://localhost:3000 ...
√ Prepped for launch
Warning: You have enabled experimental feature(s).
Experimental features are not covered by semver, and may cause unexpected or broken application behavior. Use them at your own risk.

> Using "webpackDevMiddleware" config function defined in default.
[ info ]  bundled successfully, waiting for typecheck results...
[ wait ]  compiling ...
Attention: Next.js now collects completely anonymous telemetry regarding usage.
This information is used to shape Next.js' roadmap and prioritize features.
You can learn more, including how to opt-out if you'd not like to participate in this anonymous program, by visiting the following URL:
https://nextjs.org/telemetry

[ info ]  bundled successfully, waiting for typecheck results...
[ ready ] compiled successfully - ready on http://localhost:3000

good second issue kinfeature-change scopserver statuassigned statuin-review

Most helpful comment

I think it's probably not worth prompting the user, we should just keep incrementing by 1 until we find an open port

All 13 comments

Yup, noticed this today. We should add a CLI prompt to run it on another PORT or exit

I'd like to work on this issue 😃

I think it's probably not worth prompting the user, we should just keep incrementing by 1 until we find an open port

I was checking this issue and it seems to be a problem in Next.js since they already check if a process is running on the same port but Nodejs doesn't throw an error if you have a process running on 0.0.0.0 as host with another running on 127.0.0.1 or localhost. For instance, CRA uses 0.0.0.0 as fallback for host and Next.js uses localhost, that's why Next.js doesn't throw an error about _port already in use_.

I left a comment in an old issue in Next.js repo and I think we want to fix it on their side, right?

I think the first solution is to ensure Next.js cli arguments are passed through from blitz start to next dev. next dev already accepts a port parameter

If we can add inteligence for detecting port already in use, then let's add that too.

@dwightwatson also opened an issue for this (#361) and he has a very good point that we are currently using -p for "production" instead of port.

  • So we need to remove the -p alias and only have --production for production.
  • Then -p will be for PORT, like other frameworks.

From @dwightwatson

What do you want and why?

I want to be able to run the development server on a different port, in case I'm running multiple Blitz apps side by site, or I'm using port 3000 for something else. Next.js lets you do this with the -p or --port flag - for example next start -p 8000.

Possible implementation(s)

This is a little hairy because blitz start already has a flag -p for production. I'd like to propose instead that -p be used for port as it's more consistent with Next.js, and then use a different flag like --production instead. I actually think that's a win/win because it's much more explicit and obvious when you're starting the server in production mode.

I think it's a matter of accepting a port argument in the CLI and forwarding it to the startNextDev method.

Additional context

Off the top of my head a number of other development servers use -p for the port - like Gatsby and Rails. I feel that it's pretty conventional in a way and so it would help Blitz to be consistent.

@ivandevp This is ready for you to work on if you still want!

@flybayer for sure! I'll start working on it today.

I previously said we just need to pass through all args to Next.js. That would make this work, but I realized what we really should do is add all the Next.js CLI options directly into our CLI.

This way blitz start -h will show all the available options. Next supports the following:

        --port, -p      A port number on which to start the application
        --hostname, -H  Hostname on which to start the application

So add those into blitz start exactly the same, and pass those args to Next if used.

we need to remove the -p alias and only have --production for production

could we switch to --mode=production to mirror what webpack does? that would hopefully reduce a fair amount of confusion around those

How is that better than --production? Seems like unnecessary extra typing to me :)

I don't think it's better than --production necessarily, but I think a lot of people may see --production is valid (in the package.json) and instinctively try to shorten it to -p and be surprised when it does something totally different

Ok yeah. Then let's go ahead and keep --production for now

Was this page helpful?
0 / 5 - 0 ratings