live-share
live-share copied to clipboard
Make liveshare.shareServer command automatable
One of the few annoying things about using liveshare is that I have to go start up like 4 shared servers when developing with my team. It would be way cool if the liveshare.shareServer command could take arguments (like port and displayName) so the process could be called from a task in the workspaces tasks.json. like:
{
"version": "2.0.0",
"tasks": [
{
"label": "share-servers",
"command": "${command:liveshare.shareServer}",
"args": [
"3333",
"frontend"
]
},
]
}
Any update on this ? I would be interested in this functionality as well.
I am trying to automate livesharing through an extension for our students.
I just discovered that if I'm launching my gulp process (which contains browsersync) in an integrated terminal before sharing with live share, port 3000 and 3001 are automagically shared.
That's super nice, but how does that work and how can we extend that for other ports/services ?
If I'm remembering correctly, we check the terminal output and look for common URLs. I think we look for ports
3000,
8080,
4200,
80,
5000,
8000,
5500,
3001,
8081,
4000,
9000,
8888,
443,
5001,
8082,
9090,
7071
and URLS like
http://localhost:3000/ - commonly used across multiple frameworks
https://127.0.0.1:5001/ - ASP.NET
http://:8080 - Beego Golang
http://0.0.0.0:4000 - Elixir Phoenix
Note you can programmatically share a server from an extension using Live Share's extensibility API, vsls, with the shareServer
method. Would that work for you?
I also like the idea of having a setting like proposed for simpler scenarios. I'll tag this as a feature request to track that.
Thank you so much, I just wrote a simple script that echos a list of url using those ports and it works perfectly :)
This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically in 2 days.
We’re not able to prioritize this issue over the other higher-impact issues we receive every week, based on the votes and comments from others in the community and our understanding of the issue. However, rest assured that we love your input. If you feel it deserves to stay open, then clarify your use case and contact us to let us know how severe it’s for you.