Language-tools: Types d'éléments intégrés remplacés

Le module charge des définitions de type globales, certaines des définitions de type React. Il y a d'autres personnes qui ont ce problème, il semble qu'il n'y ait pas encore de bonne solution à ce problème, mais des solutions de contournement existent
https://github.com/microsoft/TypeScript/issues/17042
https://github.com/microsoft/TypeScript/issues/18588

Il existe une solution de contournement possible , vous pouvez peut-être essayer vous-même. Nous pourrions également ajouter cette solution de contournement au référentiel si cela est faisable.

Merci pour l'avertissement @dummdidumm. Ça a marché! Pour référence:

tsconfig.json :

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "react": ["sink.d.ts"]
    }
  }
}

sink.d.ts :

declare module 'react';

Est-ce quelque chose qui pourrait être ajouté au serveur de langue lui-même ou cela gâcherait-il les choses pour un utilisateur qui souhaite réellement utiliser les types de React sur son projet ?

Je ne pense pas. Même s'il le fait, le serveur de langue ne fonctionne que sur des fichiers sveltes, donc s'il est dans un fichier tsx/jsx, tout devrait fonctionner. Je vais ajouter quelque chose.

Vous pouvez tester cela sur nightly build .

Est-il déjà déployé dans la construction nocturne ? Cela ne semble pas fonctionner malheureusement. Cependant, je pense que baseUrl est requis si paths est également configuré dans tsconfig.json https://www.typescriptlang.org/docs/handbook/module-resolution.html#path -cartographie. Je peux essayer d'ajouter le baseUrl à mon environnement local pour vérifier si cela fonctionnera.

Oh peu importe. Il semble que les changements n'aient pas encore été déployés dans la version nocturne. Je le testerai à nouveau demain.

Merci de l'avoir signalé, il y a eu une erreur dans le pipeline de déploiement (l'ordre a été foiré, donc l'extension a été construite avec les packages npm de la veille).

Désolé pour la lenteur de la réponse @dummdidumm. J'ai testé le correctif et malheureusement cela ne fonctionne pas, mais j'ai joué et trouvé les correctifs nécessaires :

1. Ici, il devrait être configJson.compilerOptions.paths au lieu de configJson.paths . Petit bug :)
   https://github.com/sveltejs/language-tools/blob/9b936fca70c03f86474aec40773c29a9b38805c2/packages/language-server/src/plugins/typescript/service.ts#L189 -L190

2. Cela ne fonctionne pas sans une option configJson.compilerOptions.baseUrl . C'est un peu plus difficile à corriger. Tout d'abord, nous devons vérifier si un est déjà défini et sinon, le chemin heureux est bien sûr configJson.compilerOptions.baseUrl = '.' . Cependant, s'il est défini, nous devons résoudre notre chemin par rapport à ce que l'utilisateur a défini comme URL de base. Cela rend les choses un peu plus compliquées, mais je suis sûr qu'il existe un moyen de le concevoir. Je n'ai pas le temps d'examiner l'atm, mais je voulais le porter à votre attention.

Je ne suis pas sûr d'avoir besoin de baseUrl , car les types qui sont définis ont un chemin absolu. Je pense que le service ts honore cela.

Merci d'avoir signalé l'erreur compilerOptions 😃 Correction qui a résolu le problème de saisie.

Remarque à propos de svelte-check : Si vous rencontrez toujours cette erreur demain, mais plus dans l'IDE, essayez de désinstaller et de réinstaller svelte-check , la dépendance transitive svelte-language-server pourrait ne pas être mise à jour vers le dernière version.

Merci pour le suivi @dummdidumm ! Je l'ai testé à nouveau et je peux confirmer avec certitude que le correctif ne fonctionne pas si compilerOptions.baseUrl n'est pas défini :grinning: Cependant, la bonne nouvelle est que si l'utilisateur a défini des baseUrl , cela n'affecte pas la résolution du remplacement de réaction car il s'agit d'un chemin absolu. J'avais tort de penser que nous aurions besoin d'un hacker pour le faire fonctionner.

Si vous avez testé la solution actuelle et l'avez fait fonctionner, vérifiez qu'il n'y a pas de compilerOptions.baseUrl configuré dans le tsconfig.json votre environnement de test ;)

Les documents sont ajoutés. Je vais laisser cela ouvert pour l'instant afin qu'il soit plus facile de le découvrir au cas où quelqu'un obtiendrait l'erreur mais ne lirait pas la section de dépannage.

Bonne nouvelle, cela a été corrigé en tant qu'effet secondaire de #351, après la prochaine version de production, la solution de contournement avec les éviers n'est plus nécessaire.

Merveilleux! Merci pour l'information! :tada: