Workspace/InitPackage: Add .vscode to .gitignore

[czechboy0]

Motivation:

When using VS Code, this directory gets created, but generally isn't meant to be checked in, similar to Xcode' xcuserdata.

Modifications:

Added .vscode to the generated .gitignore for new packages.

Result:

When creating a new package, when an adopter uses VS Code, they won't have to add this entry into their .gitignore by hand.

[MaxDesiatov]

@swift-ci test

[dschaefer2]

I always wondered that. There are somethings in there that could be shared. Given Paul merged it, I'll assume that you are correct :).

[MaxDesiatov]

yeah, I now remember it's vscode/launch.json something or other always auto-generated, but maybe there's not much else maintained manually in most repositories to track?

[dschaefer2]

You can add more launch configurations by hand. I do that when running SwiftPM with various options when testing. Also the tasks.json has the build configurations which I sometimes change to add verbosity, etc.

Mind you it's a problem with VSCode that those things aren't separated out to user and shared like Xcode does.

[plemarquand]

I may have been too quick to automerge this. While its true that there are some things in .vscode that you may not want to commit it is still useful to have {settings,tasks,launch,extensions}.json checked in to share configuration with your team.

As a result may want more granularity here than just all of .vscode. See this example .gitignore: https://www.toptal.com/developers/gitignore/api/visualstudiocode

[MahdiBM]

Like @dschaefer2 mentions, you can manually add stuff to vscode/launch.json, like creating new Xcode schemes with specific env vars etc... we do use this in a team project.
There are also some other files like extensions.json (e.g. for extension recommendations to install) and settings.json to share workspace settings.

In a few projects Swift that I've set up VS Code on, we do share all those files out of necessity.

I can see how you might not want to share some of the files, but ... I think you should? I'm not a huge VS Code user so not sure what is the consensus in their community, but sharing these files in a few teams, they have only been helpful.

For example when sharing settings.json, if there is settings that different users don't agree on, then you simply should remove that setting from settings.json, and let VS Code fallback to user settings.

Using settings.json you can for example set the settings for formatters of each filetype, or indentation settings, so contributors can easily work on the project without violating the project's general style.