I hit a problem where I had port 3000 running locally, and then opened a dev container with "forwardPorts": [3000]. Since the port conflicted, the port was actually mapped to 3001 locally. However, I had no idea, and couldn't figure out why updates weren't taking effect. I finally realized what was going on.
This doesn't happen with appPort because it actually errors if the port is already in use.
Repro:
"forwardPorts": [3000].Expected: Notified that a different local port was used, or it errors
Actual: No notice, no error
I'm not sure we want this to be a notification. The user might not care about all the forwarded ports.
@chrmarti Yeah, I understand not wanting to have notification spam, but if they went to the trouble of adding the forwardPorts property, they do care. Only the Azure Functions definitions include it by default - and that's because you do always access the function on the same port.
In many ways, the old erroring behavior was less confusing. However, since there's no way to declare a different port mapping, there needs to be some way to let you know things are not how you configured them in the json file. Given how common it is to use certain ports in multiple apps (3000, 5000, 8080), I could see this easily happening.
@chrmarti Forgot to mention - I'm not suggesting always notifying, but rather notifying in this exception case.
There is also the team scenario where a user uses a devcontainer.json where they didn't author the forwardPorts themselves and might not care about all ports.
We could handle that with a 'Don't Show Again' button. Maybe writing to a setting, so it is easy to reset and syncs across machines.
Most helpful comment
There is also the team scenario where a user uses a devcontainer.json where they didn't author the forwardPorts themselves and might not care about all ports.
We could handle that with a 'Don't Show Again' button. Maybe writing to a setting, so it is easy to reset and syncs across machines.