3 ms·

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 wor

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-project-for-codespaces/adding-a-dev-container-configuration/introduction-to-dev-containers 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.

dmix 3y ago
That's perfect, thank you.
ohthehugemanate 3y ago
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.
- snicker7 3y ago
  You can still utilize code spaces with other IDEs and text editors. It’s just a matter of SSHing into them.
  - ohthehugemanate 3y ago
    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.
    - dmix 3y ago
      Any luck getting other team members to use it?
      - ohthehugemanate 3y ago
        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. <Principal Skinner on the playground, the children who are wrong>
WorldMaker 3y ago
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.)

dmix 3y ago

That's perfect, thank you.

ohthehugemanate 3y ago

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.

snicker7 3y ago
You can still utilize code spaces with other IDEs and text editors. It’s just a matter of SSHing into them.
- ohthehugemanate 3y ago
  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.
  - dmix 3y ago
    Any luck getting other team members to use it?
    - ohthehugemanate 3y ago
      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. <Principal Skinner on the playground, the children who are wrong>

WorldMaker 3y ago

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.)