Dois-je valider le dossier .vscode au contrôle de code source?

294

Le .vscodedossier est-il destiné à être validé pour le contrôle de code source?

Dans un nouveau projet, le dossier est vide, à l'exception du settings.jsonfichier. Quel genre de choses iraient dans ce dossier? Est-il spécifique à la machine, spécifique au développeur comme le .vsdossier et donc ne pas être validé? Ou tous les développeurs devraient-ils partager ce dossier et donc il devrait être validé?

Le commentaire en haut du fichier .vscode/settings.jsonindique:

// Place your settings in this file to overwrite default and user settings.
{
}

Cela semble impliquer que le dossier doit contenir des paramètres spécifiques au projet et donc être inclus dans la source. De plus, ce post sur UserVoice semble impliquer que certaines saisies y entreraient, suggérant également qu'il devrait être validé.

visual-studio-code Ronald Zarīts
la source
Si vous démarrez un projet dans Visual Studio, puis le validez, il devrait y avoir un bon démarrage (au moins typique) .gitignore FE. S'il est censé être là, il le sera probablement. Vous pouvez également référencer ce que j'ai utilisé sans problème.
ChiefTwoPencils
2
Une bonne idée, @ChiefTwoPencils! Pour mémoire, la valeur par défaut .gitignorecréée par Visual Studio a un .vscodedossier exclu à ce stade. Mais comme VS Code est lui-même plutôt nouveau, ils ne l'ont peut-être pas encore fait. J'ai laissé le dossier non suivi pour l'instant pendant que j'obtiens plus d'informations à ce sujet.
Ronald Zarīts

Réponses:

313

Vérifiez dans le .vscodedossier si vous souhaitez partager les paramètres, la configuration des tâches et la configuration de débogage avec l'équipe. Je pense qu'en général, il est logique de partager les paramètres (par exemple, les espaces blancs vs les onglets) avec l'équipe si vous souhaitez appliquer les paramètres dans une équipe. Dans l'équipe VS Code, nous partageons également des paramètres spécifiques de débogage et de tâche, car nous voulons que notre équipe ait le même ensemble de cibles de débogage et de cibles de tâche pour VS Code.

Btw vous n'avez pas besoin d'avoir un .vscodedossier dans votre projet pour les paramètres. Vous pouvez également configurer les paramètres au niveau utilisateur.

Benjamin Pasero
la source
54
Merci! "Nous dans l'équipe VS Code ..." est assez bon pour moi - pour commencer, au moins!
Ronald Zarīts
97
Si vous souhaitez partager des paramètres de niveau fichier tels que "espaces blancs vs onglets", vous devriez plutôt envisager une solution multi-éditeur comme EditorConfig .
Tanz87
2
Ce répertoire possède un sous-répertoire "chrome" de 80 Mo. Êtes-vous sûr que cela doit être validé dans le référentiel?
ygoe
10
Vous ne devez pas utiliser VSCode pour quelque chose comme un projet python où les paramètres de l'espace de travail vont avoir des chemins python spécifiques à l'environnement pour des choses comme VirtualEnv ou les environnements Anaconda. La vérification de ces fichiers dans des sons comme un énorme problème pour la plupart des scénarios. Archivez plutôt un exemple / fichier par défaut.
StefanGordon
3
Suivi sur symbols.json: stackoverflow.com/questions/51876769/…
ripper234
39

Entre commit / ignore, il y a une troisième option intelligente: commit avec .defaultsuffixe.

Par exemple , vous pouvez ajouter settings.jsonà .gitignore, et engager settings.json.default, tout comme il est pratique courante (dans mon équipe) avec.env des fichiers.

J'ai pris ce conseil des paramètres de l'éditeur de validation vidéo au contrôle de version? par Mattias Petter Johansson

Tymek
la source
5
A settings.json.defaultest logique, mais cela suppose que toute votre équipe utilise le code vs et que votre base de code n'est pas partagée avec un public plus large. Je trouve que mes projets open source sur GitHub, je m'assure juste de l'ajouter à mon gitignore par défaut, car je ne veux pas forcer un IDE particulier sur mes utilisateurs potentiels de ma base de code.
jamescampbell
2
@jamescampbell L'ajout de fichiers spécifiques à l'IDE n'impose presque jamais cet IDE à qui que ce soit - cela leur donne simplement la possibilité d'obtenir vos paramètres d'environnement communs s'ils utilisent cet IDE. La plus grande question est de savoir si ces fichiers sont officiellement pris en charge - c'est-à-dire destinés à être toujours à jour et à fonctionner. Théoriquement, vous pouvez avoir plusieurs fichiers d'environnement IDE pour différents IDE tous présents sans aucun conflit.
LightCC
23
  • ne commettez jamais .vscode/settings.json- à l'exception bizarre de search.exclude. Si vous en avez vraiment besoin, faites très attention de ne mettre que les paramètres particuliers de votre projet que vous souhaitez appliquer aux autres développeurs.
  • pour la validation, le formatage, l' utilisation de la compilation d' autres fichiers comme package.json, .eslint, tsconfig.json, etc.
  • Les seuls .vscode qui ont du sens à inclure sont les configurations de lancement complexes pour le débogage.
  • Attention, il pourrait y avoir une extension tierce dans votre système qui pourrait y mettre des informations privées!

Ce que vous ne pouvez pas faire, c'est copier et coller tout le fichier de contenu settings.json dans .vscode/settings.json. Je vois des gens faire cela et commettre le fichier est une atrocité. Dans ce cas, non seulement vous briserez d'autres espaces de travail, mais le pire, vous appliquerez des paramètres aux utilisateurs que vous ne devriez pas aimer l'esthétique, l'interface utilisateur, l'expérience. Vous allez probablement casser leurs environnements car certains sont très dépendants du système. Imaginez que j'ai des problèmes de vision, donc mes editor.*paramètres utilisateur sont personnalisés et lorsque j'ouvre votre projet, les visuels changent. Imaginez que j'ai des problèmes de vision s J'ai besoin de personnaliser l'éditeur utilisateur. * Paramètres pour pouvoir travailler. Je serais fâchée.

Si vous êtes sérieux, ne vous engagez pas .vscode/settings.json. En général, les paramètres qui pourraient être utiles pour un projet particulier comme la validation, la compilation, ont du sens, mais en général, vous pouvez utiliser des fichiers de configuration d'outils particuliers tels que .eslint, tsconfig.json, .gitignore, package.json. etc. Je suppose que les auteurs de vscode viennent d'ajouter le fichier pour simplifier l'expérience des nouveaux arrivants mais si vous voulez être sérieux, ne le faites pas!

La seule exception, et dans des cas très particuliers, pourrait être la recherche.

cancerbero
la source
3
Je pense que votre suggestion .vscode/settingsest trop restrictive. Utilisez .eslintou .editorconfigfichiers si vous le pouvez, mais vous devez toujours vérifier .vscode/settingssi vous voulez vraiment qu'un paramètre soit partagé entre tous les développeurs d'une équipe / d'un projet
Matt Bierner
3
Matt, pourquoi supposez-vous que tous les autres développeurs utilisent vscode? Il pourrait s'agir de personnes utilisant webstorm, vim, sublime, c'est pourquoi vous devriez travailler avec eslint, etc. et non settings.json.
cancerbero
Encore une fois, l'enregistrement est .vscode/settingslogique si vous travaillez dans une équipe qui utilise vscode ou si vous travaillez sur un projet où de nombreux développeurs utilisent vscode. Tous ces paramètres n'ont pas d'équivalents entre les éditeurs
Matt Bierner
@MattBierner assez juste, si vous développez des projets de source proche dans une entreprise qui applique l'éditeur, mais je ne pense pas que ce soit une situation courante et spécialement dans les projets open source ...
cancerbero
Le point sur les extensions tierces est très valide - À titre d'exemple, je crois que l'extension MS SQL ajoutera des profils de connexion au projet / espace de travail settings.json s'il existe - bien qu'il ne stocke pas les informations d'identification, il peut vérifier les noms de serveur, etc. .
Dan Harris
18

Résumer d'autres réponses

La recommandation consiste à exclure généralement le .vscodedossier, mais laissez certains fichiers JSON qui permettent aux autres développeurs de recréer les paramètres partagés.

Exemples de paramètres à inclure:

  • Configurations de test spécifiques à la langue pour exécuter la ou les suites de tests ( settings.json)
  • Paramètres d'extension pour les linters et les outils de formatage de code pour appliquer les règles de langue utilisées dans ce repo ( settings.json)
  • Exécuter et déboguer les configurations ( launch.json)
  • Tâches partagées - si gérées avec VS Code ( tasks.json)

Notez que certains paramètres peuvent être stockés dans le fichier de l'espace de travail ou transférés dans celui-ci à partir du dossier .vscode. Voir ci-dessous.

Exemple de .gitignorecode à utiliser (et où l'obtenir)

Voici les paramètres, comme suggéré sur https://gitignore.io . Vous pouvez y rechercher "VisualStudioCode" pour obtenir le dernier .gitignorefichier recommandé . J'utilise ce site Web comme point de départ .gitignorepour la plupart de mes nouveaux dépôts:

# Created by https://www.gitignore.io/api/visualstudiocode
# Edit at https://www.gitignore.io/?templates=visualstudiocode

### VisualStudioCode ###
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json

### VisualStudioCode Patch ###
# Ignore all local history of files
**/.history

# End of https://www.gitignore.io/api/visualstudiocode

Dans ce qui précède .gitignorefichier, la .vscode/*ligne dit d'exclure tout dans le .vscodedossier, mais les !.vscode/a_specific_filelignes tell git à « pas » ignorer certains fichiers spécifiques dans ce dossier ( settings.json, launch.json, etc.). Le résultat final est que tout est exclu dans le.vscode dossier, à l'exception des fichiers spécifiquement nommés dans l'une de ces autres lignes.

Autres facteurs et comment comprendre par vous-même ...

Inclure le .vscodedossier dans votre référentiel ne fait pas de mal personne qui utilise un IDE différent (ou un éditeur de texte / code).

Cependant, cela peut blesser d'autres personnes utilisant VS Code, si ces fichiers incluent des paramètres génériques qui nécessitent quelque chose de spécifique à votre environnement, qui est différent dans leur environnement - comme le chemin absolu dans lequel le dépôt est installé (dans lequel VS Code Python met systématiquement le pythonpathdans.vscode/settings.json ). L'essentiel est d'éviter d'enregistrer des paramètres personnalisés dans votre environnement local, de ne partager que ceux qui peuvent être utilisés par tout le monde.

Par exemple, si les fichiers de paramètres IDE ont des chemins absolus vers le référentiel ou des fichiers / bibliothèques, etc., alors c'est mauvais, ne partagez pas. Mais si toutes les références sont relatives, elles devraient fonctionner pour toute personne utilisant le référentiel (bien que soyez prudent avec les différences de spécification de chemin entre Windows / Unix ..).

À propos des paramètres d'utilisateur, d'espace de travail et de dossier

Remarque: les fichiers de paramètres du .vscodedossier ne sont généralement mis à jour que lorsque vous apportez des modifications à la version du dossier des paramètres (il semble cependant y avoir de nombreuses exceptions).

  • Si vous apportez des modifications à l' utilisateur paramètres , ils sont généralement stockés ailleurs.
  • Si vous apportez des modifications aux paramètres de l' espace de travail , ils sont normalement stockés dans le *.code-workspacedossier que vous utilisez actuellement (ils vont toujours souvent dans les fichiers de paramètres du dossier - mais vous pouvez les déplacer manuellement!).

Cela signifie que vous devez placer les paramètres personnalisés de votre PC personnel dans les paramètres utilisateur et les placer génériques pour un projet / package particulier dans les autres, dans la mesure du possible.

  • J'ai remarqué que lorsque vous utilisez l'extension Python, le .vscode/settings.jsonfichier (qui enregistre les paramètres du dossier ) enregistre toujours le chemin absolu sous le pythonpathparamètre, j'ai donc supprimé son exclusion de mes .gitignorefichiers et ne l'enregistre plus dans mes dépôts Python. Même si je l'enregistre avec un chemin relatif, VS Code le réinitialise simplement au chemin absolu.
  • Au lieu de cela, je sauvegarde simplement tout dossier que je dois utiliser dans Code comme espace de travail (par exemple, créez un myproject.code-workspacefichier avec Fichier -> Enregistrer l'espace de travail sous . De cette façon, vous pouvez contrôler ce qui va dans le fichier de l'espace de travail et l'enregistrer dans le référentiel, tout en excluant le fichier de paramètres de dossier ( .vscode/settings.json). Vous pouvez à peu près déplacer n'importe quel paramètre entre l'espace de travail et les fichiers de paramètres de dossier pour contrôler ce qui est enregistré et ce qui ne l'est pas. N'oubliez pas que le fichier de l'espace de travail remplacera tout ce qui se trouve dans le fichier de paramètres de dossier.

Le plus long et le plus court est que vous pouvez simplement utiliser un fichier d'espace de travail et y mettre les paramètres les plus courants, tout en plaçant les paramètres locaux dans le fichier de paramètres de dossier, bien que cela semble dépendre des extensions / langues que vous utilisez.

Bien sûr, vous pouvez avoir d'autres raisons d'enregistrer le .vscode/settings.jsonfichier, ou une partie de celui-ci. Ou cela peut ne pas être un problème pour les paramètres dans votre langue actuelle.

Votre kilométrage peut varier...

LightCC
la source
10

Pourquoi ne pas simplement regarder la pratique, autre que les arguments ici?

Un des plus gros projets que .vscodej'ai trouvé jusqu'à présent est Mozilla Firefox . Il semble que l'équipe de Firefox partage ses tâches courantes et les extensions recommandées.

Je suppose donc que ce n'est pas une mauvaise idée de garder .vscode, tant que vous savez ce que vous faites.

Je mettrai à jour ce post quand je verrai d'autres gros projets qui partagent .vscode.

Bumsik Kim
la source
8

Identique aux autres réponses: non.

À titre d'illustration, considérons l'approche choisie par Git 2.19 (Q3 2018), qui ajoute un script (en contrib/) pour aider les utilisateurs de VSCode à mieux travailler avec la base de code Git.

En d'autres termes, générez le .vscodecontenu (s'il n'existe pas encore), ne le versionnez pas.

Voir commit 12861e2 , commit 2a2cdd0 , commit 5482f41 , commit f2a3b68 , commit 0f47f78 , commit b4d991d , commit 58930fd , commit dee3382 , commit 54c06c6 (30 juil.2018 ) par Johannes Schindelin ( dscho) .
(Fusionné par Junio ​​C Hamano - gitster- en commit 30cf191 , 15 août 2018)

contrib: ajouter un script pour initialiser la configuration de VS Code

VS Code est un éditeur de code source léger mais puissant qui s'exécute sur votre bureau et est disponible pour Windows, macOS et Linux.
Entre autres langages, il prend en charge le C / C ++ via une extension, qui propose non seulement de construire et de déboguer le code, mais aussi Intellisense, c'est-à-dire la complétion sensible au code et des subtilités similaires.

Ce correctif ajoute un script qui aide à configurer l'environnement pour fonctionner efficacement avec VS Code: exécutez simplement le script shell Unix contrib/vscode/init.sh, qui crée les fichiers appropriés, et ouvrez le dossier de niveau supérieur du code source de Git dans VS Code .

VonC
la source
1

La réponse est "NON", car le dossier .vscode est pour cet éditeur et vous ne devez pas pousser ces paramètres personnels à repo en cas de confusion pour les autres, vous pouvez donc l'ajouter au fichier .gitignore de votre projet pour ignorer les modifications

jialin wang
la source
17
Je ne serais pas d'accord avec votre position stricte. Comme mentionné dans la réponse de @BenjaminPasero, vous n'avez pas à le faire, mais cela a du sens dans de nombreux cas, par exemple le partage de la configuration des tâches. Bien sûr, il est bon d'être attentif à ses coéquipiers et de ne pas leur imposer des préférences inutilement.
Ronald Zarīts
Oui, c'est pourquoi nous avons des paramètres utilisateur et des paramètres d'espace de travail séparés (le .vscode/settings.jsonfichier dans un espace de travail): code.visualstudio.com/docs/getstarted/… Seules des choses telles que la configuration de l'outil entrent dans les paramètres de l'espace de travail
Matt Bierner
Le dossier @ RonaldZarīts .vscode concerne les paramètres et les styles de code de votre propre éditeur, je pense que c'est juste pour votre propre usage, donc comme je l'ai déjà dit, ne poussez pas le dossier pour contrôler le flux.
jialin wang
6
@jialinwang Désolé, je l'ai déjà fait. ;) Blagues à part, il contient également des éléments qui sont utiles à partager, par exemple dans mon projet, nous avons (1) launch.json- lancer des configurations de débogage qui peuvent être non triviales à mettre en place. (2) les settings.jsonparamètres au niveau du projet, comme le compilateur TypeScript à utiliser, les règles d'espaces, (3) tasks.json- les commandes de construction. Vous pouvez choisir de ne pas partager, mais nous le trouvons utile.
Ronald Zarīts
@jialinwang Non, ils ne le sont pas. Ce sont des paramètres au niveau du dossier. Vous devez non seulement inclure le niveau supérieur, mais si vous avez des paramètres spécifiques aux sous-dossiers, vous devez également les inclure. L'important est de garder vos préférences utilisateur hors des paramètres au niveau du dossier (cela est également important pour d'autres raisons). Le genre de choses que vous devriez avoir dans vos paramètres au niveau du dossier devrait s'appliquer à tout le dossier: les formateurs, les linters, les conventions d'espaces (par exemple, couper les nouvelles lignes finales, la taille des onglets ...) ...
DylanYoung
1

Un moyen simple de conserver vos paramètres sans les valider dans votre référentiel git de projet consiste à créer un espace de travail et à y ajouter un dossier.

Quand créez-vous un espace de travail, vous devez enregistrer un fichier code-workspace. Ce fichier contient des paramètres personnalisés, enregistrez simplement ce fichier hors du référentiel git et serez libre de l'ajouter .vscodedans le .gitignorefichier.

Wendel
la source