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:
Reproduire
Utilisez /@/
import
Comportement prévisible
Tout fonctionne
Système (veuillez compléter les informations suivantes):
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?
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 où
@ 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
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".