Hacker News Reader

Comment by paxys | Hacker News Reader

FYI – you can go to github.dev (or press "." while browsing any repository) to get the same VS Code online experience, additionally with the repo automatically loaded into it.

Something else I find very confusing is that vscode.dev & github.dev are both free and run the editor fully locally in your browser. Github Codespaces on the other hand provisions a VM behind the scenes so you can run containers, build tooling and whatever else alongside the editor. That one charges by the hour.

View on HN

LPT: You can get Github Codespaces for free if you have a GitHub Student Developer Pack (which you can get one if you are a student)

Another LPT: Also, you can get Github Codespaces for free if you're a teacher!

It's such an interesting benefit of VSCode being an Electron app. It runs as a true PWA on vscode.dev/github.dev.

Other fun tips:

- The '.' shortcut to github.dev works from Pull Requests too and puts you straight into a PR review mode.

- For those stuck in Azure Repos, GitHub's increasingly zombie cousin, the '.' shortcut also works from any Files view. (Though not PRs.) It uses vscode.dev directly rather than github.dev.

github.dev now has a "Continue With..." call-to-action which spins up a Codespace, so that differentiates it a bit.

From https://github.com/jupyterlite/jupyterlite/issues/1086#issue... :

vscode://vscode.git/clone?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fvscode-vsce.git

vscode://file/path/to/file/file.ext:55:20

vscode://file/path/to/project/

  https://vscode.dev/github/organization/repo

https://vscode.dev/github/python/cpython

  https://vscode.dev/azurerepos/organization/project/repo

https://vscode.dev/azurerepos/organization/project/repo

You do get something like 60 hours free a month with Codespaces (with lowest CPU/memory), which is fairly generous.

Also - we get that the difference between all these things can be confusing. Here's a post laying out the vision for vscode.dev and why it exists at all: https://code.visualstudio.com/blogs/2021/10/20/vscode-dev

Can you share a VSCode profile across a team somehow?

We have a frontend with typescript + vue (volar) and it'd be great to have a 'standard' web VSCode interface we can share across the team as the baseline working version. So we don't have to worry about dependencies or someone seeing different error messages than others. ESlint is another one.

Our devs use 3 different IDEs so it'd be good for them to have one to compare to with having to screenshare.

Most VS Code settings can optionally be saved into the local working directory under a .vscode/ directory, which can be committed to a repo. When you open a workspace in VS Code, go to Settings. You'll see two tabs at the top: "User" and "Workspace". If you click on "Workspace", any settings you change will be saved into .vscode/ in the current directory.

You could also use a `devcontainer.json` to personalize the GitHub Workspace even further, so when people open up a Workspace, things are fully configured: https://docs.github.com/en/codespaces/setting-up-your-projec...

In VS Code, once you have an extension installed, you can go to the Extensions tab, click the more options button on a particular extension, and click "add to devcontainer.json", which seems like it would ensure that it is part of the Workspace by default.

That's perfect, thank you.

My only complaint about vscode remote containers and codespaces is that they ruined me for every other IDE, especially in a team context. I can never go back to managing dependencies for every damn language/version on my local machine, just to be able to run the linters/tests/tools I need to develop well in that language/version.

With a team, I know that everyone has the same versions of everything unless they've specifically created an exception. New team members start up the IDE with all their support tooling already in place, automated tests runnable, etc etc.

Paired with codespaces, when I need to make a quick edit as a part of PR review or just to tweak something, instead of the GH text editor I get MY IDE, already configured the way I like it with an identical run environment.

I've used many IDEs over the years, from tricked out Vim to eclipse and jetbrains... but codespaces killed them all for me. I'm sure it's not for everyone but it is amazing for me.

You can still utilize code spaces with other IDEs and text editors. It’s just a matter of SSHing into them.

Oh yes I know. But the split VSCode process is where a key part of the value lies for me. Not just that my entire toolchain is there, including tests, etc... we've had that for years with vagrant, for example. But also that the actual IDE is running there, and all contained in the repo, is awesome. I never achieved that level of seamlessness and consistency even with vim.

Any luck getting other team members to use it?

I don't dictate IDE choice on my teams, but projects definitely end up with a very convincing "happy path". 75% of the Dev market uses vscode anyway, so I never got resistance to that level. And once .devcontainer is revisioned people would have to work to AVOID using the convenient, perfectly configured environment so no resistance there, either.

At that point, GH codespaces is a convenience tool, icing on the cake for when you want to make a quick edit during PR review, or when you're away from your desk. I saw devs use it that way (and did so myself) with no resistance.

But I have big caveats to my experience:

1) my only teams since this whole toolchain came into existence were joint microsoft/customer "build with" teams, so they were more positively predisposed to MS tooling than average.

2) I've never seen a team that uses web based codespaces EXCLUSIVELY.

Even though I know the difference between vscode-in-electron-with-remote and vscode-in-browser-with-auto-provisioned-remote is academic (and performance is probably better in the browser!)... I would still struggle with how ephemeral web apps feel to me on a gut level. Plus, as an old person I am uncomfortable when my toolchain isn't 100% local. I have nothing against the children with their cloud-powered toolchains, but it's hard for me.

An alternative to devcontainer.json is that the .vscode/ "Workspace settings" directory also supports an extensions.json where the "Workspace" can suggest extensions to install. The easiest way is to go to the extension in your Extensions list (such as in the above example the Volar [Vue Language Features] extension) or in the "marketplace" and under the Settings cog menu is an "Add to Workspace Recommendations".

Developers opening the workspace after that will get a friendly notification popup to install recommended extensions if they don't have them installed. (It doesn't force the install, it simply recommends it and makes it easy to install. Which is nice, too, when Developers prefer in their own workflows to use alternatives or Preview Versions or no extensions.)

Does not appear to work in FF Edit: Just tried with 115 on an Ubuntu install and that does work with both normal & ESR 102.6. In console, get error: "No measure found in Performance API for "start.block: Bootstrap" and a 404 warning for assets.github.com/static/primer.css

I use it at work in FF. Maybe you have an extension installed that’s intercepting the “.”?

You have to be logged in to github for it to work.

Works for me in FF 115.0.2 and has worked for many months on previous versions.

The issue is that when resistFingerprinting is set to true in about:config it results in the error and stopping the JS redirect to the login screen. Interestingly, this also appears to be why windy.com broke a few weeks ago.

Do you mean to say that changes I make from GitHub.dev are reflected on my local machine?

if you commit those changes back to your repo, and pull them to your local machine, yes

Plus any VS Code settings changes you make if you have VS Code Settings Sync active.

Only works of you're logged in.

Not really unexpected is it

Even a readonly version is very useful. The tree-based file browser on the left and in-editor navigation are helpful for browsing the code. Recent github updates added a tree to the file view, making this less important, but the vscode experience is still superior.

Reply on news.ycombinator.com