Language-tools: L'alias n'est pas résolu

Créé le 20 août 2020  ·  10Commentaires  ·  Source: sveltejs/language-tools

Décrivez le bogue
J'ai utilisé l'alias d'importation @/ et cela a fonctionné. Ensuite, je suis passé à Vite et il ne prend en charge que les alias racine. J'ai donc changé mon code pour utiliser les alias /@/ . Il compile et fonctionne dans le navigateur, mais me donne une erreur dans vscode:

image

Reproduire
Utilisez /@/ import

Comportement prévisible
Tout fonctionne

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

  • OS: Ubuntu
  • IDE: VSCode
  • Plugin / Package: "Svelte for VSCode"
Fixed bug question

Commentaire le plus utile

Le problème est à l'intérieur de notre module-loader , qui délègue à la résolution TS normale car la vérification de "est un chemin absolu" est vraie (les chemins de fichiers commençant par / sont absolus sous Linux). Je pense que nous avons besoin de vérifications supplémentaires pour "ce préfixe fait-il partie des chemins tsconfig".

Tous les 10 commentaires

Vous devrez également configurer l'alias pour dactylographié via tsconfig / jsconfig.json

https://www.typescriptlang.org/docs/handbook/module-resolution.html#path -mapping

Je suis également confronté au même problème que tsc peut le compiler très bien. Cependant, des outils comme svelte-check ne pourront pas résoudre correctement le chemin d'alias et lancer des erreurs comme OP. Il semble qu'il y ait un bogue lié à language-tools incapable de résoudre correctement tsconfig.json dans le dossier du projet?

Screenshot 2020-08-21 at 13 06 57

Cette erreur est due au fait que nous avons utilisé une propriété spéciale injectée par svelte2tsx pour effectuer la vérification de type de composant. Si nous ne pouvons pas trouver le fichier réel, nous ne pouvons pas transformer le fichier en utilisant svelte2tsx.

@cayter

@ jasonlyu123 Voici la structure de mon dossier de projet qui se trouve être un monorepo pour le backend / frontend:

.
├── Makefile
├── README.md
├── database
│   └── database.rules.json
├── firebase.json
├── firestore
│   ├── firestore.indexes.json
│   └── firestore.rules
├── functions // backend code
│   ├── package-lock.json
│   ├── package.json
│   ├── src
│   │   └── index.ts
│   └── tsconfig.json
├── hosting // frontend PWA code
│   ├── ...
│   ├── src
│   │   ├── components
│   │   │   ├── App.svelte
│   │   │   └── ...
│   │   ├── images
│   │   │   ├── cover.png
│   │   │   └── ...
│   │   ├── index.css
│   │   ├── index.ts
│   │   ├── pages
│   │   │   ├── Auth
│   │   │   │   └── ...
│   │   │   ├── Error
│   │   │   │   └── ...
│   │   │   ├── Home
│   │   │   │   └── ...
│   │   │   └── User
│   │   │       └── ...
│   │   └── stores
│   │       └── ...
│   ├── svelte.config.js
│   ├── tailwind.config.js
│   ├── tsconfig.json
│   ├── vite.config.ts
│   └── workbox.config.js
├── package-lock.json
└── package.json

hébergement / tsconfig.json

{
  "compilerOptions": {
    "allowSyntheticDefaultImports": true,
    "baseUrl": "src",
    "declaration": true,
    "emitDecoratorMetadata": true,
    "esModuleInterop": true,
    "experimentalDecorators": true,
    "forceConsistentCasingInFileNames": true,
    "importHelpers": true,
    "importsNotUsedAsValues": "error",
    "isolatedModules": true,
    "lib": ["dom", "esnext", "es6"],
    "module": "esnext",
    "moduleResolution": "node",
    "noEmit": true,
    "noImplicitAny": true,
    "noImplicitReturns": true,
    "noImplicitThis": true,
    "rootDir": "src",
    "skipLibCheck": true,
    "sourceMap": true,
    "strict": true,
    "strictBindCallApply": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "strictNullChecks": true,
    "target": "esnext",
    "types": ["jest", "node", "svelte"],
    "paths": {
      "/@/*": ["*"]
    }
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules/*", "public/*"]
}

Si nous ne pouvons pas trouver le fichier réel, nous ne pouvons pas transformer le fichier en utilisant svelte2tsx.

Oui, ceci est pertinent pour la résolution de chemin d'alias défini dans le tsconfig.json n'est pas honoré. Donc, si nous le changeons en chemin relatif au lieu d'utiliser le chemin d'alias, l'extension vscode et svelte-check ne lèveront plus aucune erreur que vous pouvez voir à partir de la capture d'écran d'OP pour le composant ComboBox .

Pouvez-vous vérifier le canal de sortie de vscode, choisissez svelte dans la liste déroulante à droite. Et voyez si vous avez quelque chose comme ça
Initialize new ts service at c:/Current Projects/svelte-app/tsconfig.json et publiez le journal ici.

Je peux reproduire cela. Pour une raison quelconque, getDefinitionAndBoundSpan peut traiter les fichiers TS / JS importés de tels emplacements, mais pas les fichiers .svelte .

Le problème est à l'intérieur de notre module-loader , qui délègue à la résolution TS normale car la vérification de "est un chemin absolu" est vraie (les chemins de fichiers commençant par / sont absolus sous Linux). Je pense que nous avons besoin de vérifications supplémentaires pour "ce préfixe fait-il partie des chemins tsconfig".

OP a en fait dit que cela fonctionne avec @/ et je l'ai manqué. Désolé 😅

J'ai oublié de dire à quel point vous êtes géniaux. Merci pour votre réponse rapide

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