If you're authenticated with GitHub, visit a repo's page and press ".". A web version of Visual Studio Code will spin up in your browser. This is distinct from the Codespaces launch yesterday.
It is especially useful when reviewing pull requests because it "just works" meaning that if you hit "." while on a PR page, it opens up the branch from the work.
This saves me a lot of time as a maintainer in some cases where otherwise I'd have to add the fork as a remote and then check it out locally.
Hoping that they'll add support for terminals as well at some point though I suspect maybe that'll forever be reserved for Codespaces.
if reviewing PRs coming from forks is common for you, why don't you just write a script that will add the remote and fetch the PR. this fits straight into the "automate what I do often" philosophy, I don't think it's worth giving the power away to the browser.
That's really cool. I used to use github1s where you can replace github url with github1s and it loads vs code in browser. However you're unable to edit it so this is definitely a step up
So do you get the entire editor client side and you can read and write file (functionality that GitHub already had), but the big difference from Codespaces is that you don't have access to a linux box to run anything on? Sounds like an awesome little addition if that is the case.
Yep exactly! You have access to full-fidelity VS Code, minus the capabilities that require compute: tasks, terminals, and debugging. Over time, as extensions start to add support for this browser-local compute model, github.dev will enable new and interesting ways to learn and communicate about code:
This feels useful when I just want to explore a codebase, but maybe not need to do any extensive development. Instead of take down the repo and load it in an IDE, it can just be there to explore...
I wonder with cloud setups if I'd ever be able to provision the environment how I want it setup? I want vim with syntastic and other bindings setup along with all my dot files.... I wonder how well that would work? Or will we all be forced into a kind of vanilla IDE setup and discourage any custom setups?
It may support a dotfile repo in your GitHub account like Codespaces does, but I've never setup such a repo so I can't test.
I do use VS Code's Settings Sync with my GitHub Account. I was surprised it wasn't on by default, but the menu steps to turn it on on the GitHub Dev site were very quick (didn't have to relogin, it did know which account I was already logged in under on the main GitHub site). It synced quickly with my Settings. It even pulled in some of my extensions, the most noticeable one being a custom color theme. Other than the obvious limitation to extensions that support "Virtual Workspaces", I'm not exactly sure why the subset of supported extensions is what it is. But it's neat that some of them show up. ("Virtual Workspaces" has been an interesting project to follow in VS Code's release notes and lets you do something similar to GitHub.Dev in your locally installed VS Code as well: open a remote GitHub repo you've never cloned/downloaded.)
(I have a Vim emulation extension to VSCode in my Settings Sync, but currently disabled for reasons in that I haven't used it in a while. It shows up as supported in the Extensions list on GitHub.Dev, which is interesting. Might try reenabling it and seeing how it works these days.)
After turning on Settings Sync once in GitHub.Dev it seems to remember it on subsequent visits (even from different repositories). Pretty neat.
It looks like GitHub.Dev only supports VS Code. If you want to provision an environment how you want it setup you could use Codespaces the next step up "big brother" tool to this GitHub.Dev site. (That gives you the ability to specify a full Docker container the Codespace runs in, including things like port forwarding SSH to allow working with vim, which GitHub mentioned doing in their recent Engineering blog about moving to Codespaces.)
Yes, it seems like a free "Lite" version of Codespaces for every repo whether the repo has paid for and enabled Codespaces or not. It seems to be using the recent "Virtual Workspaces" support in VS Code, just using a browser-hosted VS Code rather than a local install, so some of the VS Code extensions supported in Codespaces won't work in this GitHub.Dev "every repo" version.
Codespaces clones your repo to a VM that you have full access to, github.dev is “serverless”: it operates in your browser and all interaction happens via the GitHub API
This is prety cool, I must say. Not all extensions are "available" though, so you may end up with an unsupported language without syntax highlighting (like for example zig).
FWIW, I had to disable Privacy Badger on github.dev, or it would not work. Complaining about not being able to resolve resources.
Well, solutions like docker, Ansible, vbox and Nix provide a containerized dev environment and help with requirement provisioning.
Codespaces, github.dev and github1s also kinda help with this although with a focus on helping on-boarding new team members. But IMO, in future, this could have features like export Dockerfile or any other format github desires.
This saves me a lot of time as a maintainer in some cases where otherwise I'd have to add the fork as a remote and then check it out locally.
Hoping that they'll add support for terminals as well at some point though I suspect maybe that'll forever be reserved for Codespaces.