ember-cli / ember-cli

The Ember.js command line utility.

Home Page:https://cli.emberjs.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

--port=4200 not working

amk221 opened this issue · comments

We use --port and --test-port for consistent (bookmarkable) links to localhost. Since the new auto port picking feature has gone in, this has stopped working:

Before

ember server --port=4200
Serving on http://localhost:4200/

After

ember server --port=4200
Serving on http://localhost:4201/

This happens when port 4200 is already in use, and you'd otherwise have an error, and your dev server would not start (two servers are not allowed to run on the same port at the same time).

If you don't have a duplicate server on 4200 running, let me know!

If I ask for a specific port and its not available, shouldn't it error? As in, I'd only expect auto-behaviour when no port is specified

Nay, because you want to get to developing, and if you do run multiple prajects on your computer, it's a convenience to just get to your work, rather guessing a new port.

Here is the implementation pr for discussion: #10394

Fair enough. I can work with that, it just means our work flow might change.

Spin up watchers

cd app1
npm run watch          # port 4200
npm run watch:tests    # port 4201
cd app2
npm run watch          # port 4300
npm run watch:tests.   # port 4301

The difference being that now, developers can accidently do:

cd app1
npm run watch          # port 4201     CLASH: app server running on test server location

Anything goofy with the watch modes always booting, rather than erroring?

Do you have other tools that are expecting fixed port numbers?

If I ask for a specific port and its not available, shouldn't it error? As in, I'd only expect auto-behaviour when no port is specified

This is what I also would expect to happen and is what the PR description mentions as well:

ember serve will now automatically choose a port (starting with 4200), unless a port is explicitly set with the --port flag or the $PORT env variable.

I haven't tried it, but looking at the implementation I would expect --port 4201 to throw an error if that port is already in use, instead of selecting a different one automatically. So I do think it's a bug that the default port (4200) doesn't do that.

Unrelated, but it probably would also be a lot clearer if an extra message was displayed when a port is occupied and a different one was selected.

I can get behind that -- would you be willing to open a PR?