3 ms·

> Github "left our macOS model behind and moved to Codespaces for the majority of GitHub.com development". Yikes. I wasn't planning on working at GitHub, but

> Github "left our macOS model behind and moved to Codespaces for the majority of GitHub.com development". Yikes. I wasn't planning on working at GitHub, but I definitely wouldn't if that quote is genuine. Imagine actually being forced to use VS Code to do your work. I love VS Code, but it seems wrong to center the team's workflow around it. I guess you're screwed if you want to use Vim or Sublime? "Oh, but there's plugins for that!", I can hear someone say. Yeah, f--- that sh--. And after all, who's to say that GitHub Codespaces won't someday drop VS Code when it's no longer in vogue? GitHub Classroom touted its Repl.it integration and then deprecated it almost immediately without an equivalent alternative (just use VS Code bruh), so it's not that farfetched.

danielvaughn 4y ago
I agree that being literally forced to use Codespaces is kind of shitty. On the other hand, establishing code consistency is important, and it all depends on your editor's linter/prettier. They have to produce the same output, and even managing that within the same editor is difficult because you might have different versions on each dev machine, or different user settings. Doing so across editors is even more difficult.
- thebean11 4y ago
  Prettier / linter can just be run in a git hook and verified in a GitHub action / CD step though. Prettier config should be committed to the repo itself, then let devs decide how they want to apply it to their workflow (and prevent them from merging otherwise).
- gscho 4y ago
  There's also the benefit of "dog fooding" their own product that they're selling to customers.
thebean11 4y ago
The "run the whole dev environment in the cloud" part actually sounds pretty nice. 10 seconds to have everything running?? And I assume you can switch between multiple environments you have saved, tied to branches? That's pretty sweet and opens up tons of opportunity for server side build caching to speed things up (don't need to compile the packages you aren't modifying). Is VS Code actually required, or is there some way you can edit source code locally then push to codespaces to actually run it?
- gscho 4y ago
  Emacs and vim are supported!
  - thebean11 4y ago
    What about JetBrains IDEs though? What if I want to run some one-off script on my local terminal that's interacting with source code files? Emacs and vim plugins don't go far enough IMO, it needs to fully support the local filesystem.
    - simonw 4y ago
      Can JetBrains IDE open and edit files over SSH? If so, it will work with Codespaces.
easton 4y ago
They covered that in the original blog post, as a ton of their internal devs liked their current setup. They ended up writing a little command line utility that would let you SSH into your codespace (spinning it up if necessary), so you could use whatever editor you want (including JetBrains IDEs now that they have good SSH support). https://github.blog/2021-08-11-githubs-engineering-team-moved-codespaces/ https://github.blog/2021-08-11-githubs-engineering-team-move... (and if you want to try it, I think it's "gh cs ssh" in the github cli)

danielvaughn 4y ago

I agree that being literally forced to use Codespaces is kind of shitty. On the other hand, establishing code consistency is important, and it all depends on your editor's linter/prettier. They have to produce the same output, and even managing that within the same editor is difficult because you might have different versions on each dev machine, or different user settings. Doing so across editors is even more difficult.

thebean11 4y ago
Prettier / linter can just be run in a git hook and verified in a GitHub action / CD step though. Prettier config should be committed to the repo itself, then let devs decide how they want to apply it to their workflow (and prevent them from merging otherwise).
gscho 4y ago
There's also the benefit of "dog fooding" their own product that they're selling to customers.

thebean11 4y ago

The "run the whole dev environment in the cloud" part actually sounds pretty nice. 10 seconds to have everything running?? And I assume you can switch between multiple environments you have saved, tied to branches? That's pretty sweet and opens up tons of opportunity for server side build caching to speed things up (don't need to compile the packages you aren't modifying). Is VS Code actually required, or is there some way you can edit source code locally then push to codespaces to actually run it?

gscho 4y ago
Emacs and vim are supported!
- thebean11 4y ago
  What about JetBrains IDEs though? What if I want to run some one-off script on my local terminal that's interacting with source code files? Emacs and vim plugins don't go far enough IMO, it needs to fully support the local filesystem.
  - simonw 4y ago
    Can JetBrains IDE open and edit files over SSH? If so, it will work with Codespaces.

easton 4y ago

They covered that in the original blog post, as a ton of their internal devs liked their current setup. They ended up writing a little command line utility that would let you SSH into your codespace (spinning it up if necessary), so you could use whatever editor you want (including JetBrains IDEs now that they have good SSH support). https://github.blog/2021-08-11-githubs-engineering-team-moved-codespaces/ https://github.blog/2021-08-11-githubs-engineering-team-move... (and if you want to try it, I think it's "gh cs ssh" in the github cli)