Language-tools: VSCode : le formateur est lent ou se bloque si jsconfig.json est présent dans le projet

Créé le 6 nov. 2020  ·  19Commentaires  ·  Source: sveltejs/language-tools

Décrivez le bogue
Depuis la mise à jour vers 105.4.0 de l'extension VS Code, le formateur est vraiment lent ou se bloque lors de l'enregistrement d'un fichier .svelte, ce qui m'oblige à ignorer le formatage à partir de l'invite VS Code presque chaque fois que j'enregistre un fichier.
Il y a un jsconfig.json présent dans le projet, il y a quelques alias mappés à la racine de mon projet.

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "#js/*": ["./client_src/js/*"],    
      "#api/*": ["./server_src/api/*", "./client_src/js/api/*"],
      "#api/scripts/*": ["./server_src/scripts/api/*"],
      "#api/webapps/*": ["./server_src/webapps/api/*"],
      "#api/restapps/*": ["./server_src/restapps/api/*"],
    }
  },
  "exclude": ["node_modules"]
}

https://code.visualstudio.com/docs/languages/jsconfig

Si je supprime ce fichier, le formateur fonctionne comme prévu.

La version 102.3.0 n'a pas ce problème, j'ai rétrogradé à cette version entre-temps.

Reproduire
Ajoutez un fichier jsconfig.json au projet, le contenu ne semble pas avoir d'importance.
J'ai ajouté un fichier jsconfig.json vide, ou avec un objet vide, ce qui provoque le blocage du formateur.

Comportement attendu
Formatez le code sans geler.

Captures d'écran
image

Système (veuillez compléter les informations suivantes) :

  • Système d'exploitation : Windows 10
  • IDE : VS Code
  • Plugin/Package : Svelte pour VSCode 102.4.0 102.5.1
question

Tous les 19 commentaires

Pouvez-vous essayer d'ajouter inclure et exclure (https://www.typescriptlang.org/docs/handbook/tsconfig-json.html) Nous exclurons les node_modules et le fichier dist par défaut s'il n'y a pas de tsconfig ou jsconfig.

Peut-être que #639 a-t-il en quelque sorte de mauvais effets secondaires, s'exécutant trop souvent/prenant trop de temps dans ce cas ?

Votre exclude correct ? Je ne vois pas quelque chose comme dist là-dedans, peut-être qu'à cause de #639, le dossier dans lequel les fichiers sont générés (comme dist ) est analysé à chaque fois et les fichiers sont ajoutés, car c'est pas exclu.

J'ai modifié l'exclusion et maintenant cela semble mieux fonctionner. Si je recharge l'éditeur, le premier formatage est toujours lent, mais tous les suivants fonctionnent comme prévu maintenant (au moins depuis une demi-heure que je le teste).
Ajout de dist au cas où, mais le dossier dist était vide et j'avais toujours des problèmes.

{
  "exclude": ["node_modules", "**/node_modules", "dist"]
}

C'est un projet assez ancien et volumineux où les fonctionnalités du CMS sont construites sous forme de modules séparés qui sont complètement autonomes, de sorte qu'ils ont tous leur propre dossier node_modules et package.json pour gérer les dépendances de ce module.
L'extension Svelte génère ceci, il y a donc quelques fichiers

SnapshotManager File Statistics:
Project files: 527
Svelte files: 32
From node_modules: 1342

Je viens d'introduire Svelte il y a quelques mois et ça marche très bien jusqu'à maintenant.

527, c'est encore beaucoup pour moi. C'est vraiment une grande application.

Notez que la plupart des problèmes de performances de formatage signalés ne sont pas réellement un problème de formatage, mais un problème de performances plus général. C'est juste que le formatage est plus facile à repérer. Nous devons probablement encore peaufiner les performances ici et là.

Je suppose que la plupart de ces fichiers proviennent des autres projets. Parce qu'il n'y a que le jsconfig à la racine, tout est chargé même s'il n'est pas nécessaire. Je pense aussi qu'on ne peut pas faire grand-chose là-bas. Le chargement initial est probablement le service TS qui lit le fichier de configuration, puis qui analyse et charge initialement tous les fichiers js/ts. Comme c'est synchrone, nous sommes essentiellement empêchés de faire autre chose.

Oui, c'est un site Web assez volumineux qui date de quelques années et qui est en cours de développement.
Il existe quelques applications Svelte autonomes utilisées comme modules pour les éditeurs.
Ainsi, la majeure partie de la base de code n'est pas liée à Svelte, mais tout se trouve dans le même référentiel.

L'exclusion des dossiers node_modules plus profondément dans la structure semble avoir résolu mon problème pour le moment.

J'ai eu le même fichier jsconfig pendant des années dans le projet sans aucun problème auparavant, il a été modifié pour la dernière fois il y a 2 ans.

Si vous n'avez pas besoin de faire référence à ce problème pour peaufiner les performances, nous pourrions probablement le fermer

Je ne pense pas que ce soit lié à votre problème, mais j'ai également de très mauvais comportements de ralentissement.

On dirait que c'est toujours un pas ou un changement en arrière ou quelque chose ? Signaler des erreurs est assez incohérent.

J'ai besoin de plus d'informations sur votre projet et la situation dans laquelle il se déroule.

  • cela se produit-il sur tous les fichiers ou seulement sur les gros ?
  • qu'est-ce que cela affecte? Saisie semi-automatique ? Diagnostique? Tout?
  • quelle est la taille de votre projet ?
  • utilisez-vous des préprocesseurs comme le tapuscrit ? Si oui, lesquels ?
  • jetez un œil à output>Svelte et voyez s'il y a quelque chose de suspect là-dedans. Il y a aussi un rapport de statistiques de fichier toutes les quelques minutes, pourriez-vous le coller ici lorsque la lenteur se produit ?

Si le repo n'est pas privé, ce serait formidable si je pouvais y jeter un œil.

J'essayais de ne pas ouvrir un problème séparé inutilement, mais je pense que mon problème est peut-être suffisamment différent pour qu'il en appelle un. Je vais aussi essayer de faire un repo minimal. Le projet est petit.

J'ai également une expérience de formatage très lente mais sans jsconfig.json.
Au lieu de cela, j'utilise dactylographié avec un tsconfig.json. Un regard sur les spectacles de Svelte Output

SnapshotManager File Statistics:
Project files: 15
Svelte files: 71
From node_modules: 473
Total: 567

J'exclus node_modules dans le tsconfig mais le résultat est le même et je soupçonne que c'est la raison des mauvaises performances.
Aucune suggestion? Merci.

Le formatage n'est-il lent qu'au démarrage ou tout le temps ? Ne serait-ce qu'au démarrage - on ne peut pas faire grand chose, tous les fichiers sont chargés au démarrage et cela bloque l'extension pendant un petit moment.
J'aurais besoin d'un minimum reproductible pour affiner ce problème.

Il est difficile de généraliser le problème. Les petits projets ne semblent pas être affectés, du moins pas tant que ça. Mais mes "plus gros" projets se comportent comme ceci :
Le formatage devient plus lent avec le temps. Les fichiers plus petits fonctionnent parfaitement après le démarrage de Vs Code. Mais pour certains fichiers plus volumineux (~15 importations d'autres composants sveltes, 300 LOC) le formatage est lent (prend environ 10-15 secondes) depuis le début et ne fait qu'empirer. Les fichiers plus petits semblent ralentir avec le temps, mais c'est difficile à reproduire.

Que puis-je faire pour obtenir des informations plus utiles pour vous? Je ne peux pas vous envoyer le projet, car il s'agit de trucs internes pour un client.

Pouvez-vous l'anonymiser d'une manière ou d'une autre ? Ainsi, par exemple, supprimez toutes les dépendances internes, extrayez un gros composant et remplacez son contenu par des éléments lorem ipsum et importez d'autres composants d'espace réservé. Au cours de ce processus d'extraction, vous découvrirez peut-être également que le problème n'est plus reproductible, ce qui aide à en déterminer la raison.

Je viens de réaliser ce qui pourrait être une cause, du moins pour le décalage constant dans le "grand" composant svelte:
C'est un terrain de jeu qui utilise un fichier json comme données de test (tableau avec environ 3 500 éléments).

import testData from './testData.json';

Existe-t-il un moyen pour l'outillage d'ignorer de tels fichiers ?

@kuechlerm Avez-vous trouvé un moyen d'ignorer les importations de données ?

@IgorMitev Non :(

Je suppose que vous avez défini resolveJsonModule sur true dans votre tsconfig.json ? Cela signifie que TS "importe et analyse ce fichier", ce qui est lent et non évitable. Si vous définissez plutôt resolveJsonModule sur false et fournissez une déclaration d.ts qui dit à TS de supposer simplement que tout fichier se terminant par .json est ok comme ceci :

declare module "*.json" {
  const value: any;
  export default value;
}

Ensuite, le fichier n'est pas analysé et cela devrait être plus rapide. L'inconvénient est que vous n'avez plus de définitions de type pour le module JSON et que TS n'erreur pas non plus s'il n'y a pas de fichier JSON sur le chemin que vous spécifiez.

@dummdidumm C'était un très bon conseil ! Merci.

Cette page vous a été utile?
0 / 5 - 0 notes