Open chrmarti opened 3 years ago
We've commented it out from the remote-try-* samples as we've made progress on auto port forwarding - it's left as a reference above the other ports properties to show the various ports options folks can set in their containers (i.e. in remote-try-python: https://github.com/microsoft/vscode-remote-try-python/blob/main/.devcontainer/devcontainer.json#L42).
It looks like the definitions where it isn't already empty/commented out are:
Would the proposal be:
"forwardPorts"
"forwardPorts"
from definitions where it is currently empty and from above definitions where it is not needed to make our definitions more concise
"forwardPorts"
from remote-try-* samples to make them more concise/follow the practice we decide upon here?I would remove them where they are not needed. @Chuxel mentioned: "Its still useful in scenarios where the port is spun up before VS Code is connected. (e.g. SSH, VNC, etc)." Not sure if maybe portsAttributes could be used in these cases (to lead users towards the new property instead of the old).
I just tried commenting out forwardPorts
from the PHP devcontainer.json, and I got the expected "Hello remote world!" output as I did when forwardPorts
was included.
When I have a bit more time, I can go through the other definitions I linked above that have forwardPorts
and verify if they behave the same if the property gets commented out, and then open a PR to:
forwardPorts
if possible (i.e. in the case of PHP definition)portsAttributes
(although I'm not sure since portsAttributes
sets behavior of known forwarded ports, whereas forwardPorts
will actually designate the ports to be forwarded?)
Now that auto port forwarding works reliably for Linux (by inspecting /proc), new ports trigger a notification and we have the Ports view, we could remove the
"forwardPorts"
property from most definitions. Exception being those ports that are being listened on before VS Code is up. That would simplify the devcontainer.json we generate./cc @bamurtaugh @Chuxel