Typescript: Le fichier diffère du fichier déjà inclus uniquement par la casse: casse correcte mais chemin relatif

Créé le 5 juil. 2018  ·  44Commentaires  ·  Source: microsoft/TypeScript

Error TS1149: File name 'C:/Project/frontend/scripts/State.ts' differs from already included file name '../frontend/scripts/State.ts' only in casing.

J'ai vérifié trois fois le boîtier dans nos références et les fichiers réels ont également le bon boîtier. Pour autant que je sache, c'est uniquement parce que le chemin relatif utilise une casse incorrecte, ou peut-être simplement à cause du chemin relatif lui-même?

Il compile très bien sur Mac et Linux, mais génère cette erreur sur Windows.

Bug Fix Available

Commentaire le plus utile

Je suis tombé sur cette même erreur récemment.
Après avoir fait quelques recherches sur Google, j'ai trouvé ceci . La dernière réponse a attiré mon attention. J'ai donc simplement fermé le dossier dans lequel travaillait dans Visual Studio Code et l'ai rouvert. Une fois que tout est chargé, aucune erreur et je n'ai pas eu à jouer avec le fichier tsconfig.json.

J'espère que cela t'aides

Tous les 44 commentaires

Cela ressemble à un bogue, mais nous aurons besoin d'un moyen de le reproduire. Avez-vous un fichier zip ou un dépôt ou une description des fichiers que nous pourrions utiliser?

En fait, le problème était lié à un module tiers, tsify. Notre projet utilisait la version 1.0.1 et forceConsistentCasingInFileNames n'était pas pris en charge avant la version 4.0.0.

J'ai eu le même problème avec l'un de mes composants d'importation. Le nom du répertoire du composant I était historique avec le même "h" que j'essayais de l'importer avec un "H" majuscule. Ça devrait être "
import {GraphDataComponent} depuis "./historical/graph-data/graph-data.component"; "au lieu de" import {GraphDataComponent} depuis "./Historical/graph-data/graph-data.component" dans app.moudule. ts.

Merci @aaybhangu!

Salut, je suis toujours confronté à ce problème avec - erreur TS1149: Le nom de fichier 'src / models / headers / userRole.ts' diffère du nom de fichier déjà inclus 'src / models / headers / UserRole.ts' uniquement en casse.
J'ai essayé plusieurs façons de résoudre ce problème, mais pas de chance. J'utilise Windows.

Je suis également confronté au même problème.
Pour l'instant, "résolu" en définissant:
"forceConsistentCasingInFileNames": false,
en tsconfig.json

Je suis tombé sur cette même erreur récemment.
Après avoir fait quelques recherches sur Google, j'ai trouvé ceci . La dernière réponse a attiré mon attention. J'ai donc simplement fermé le dossier dans lequel travaillait dans Visual Studio Code et l'ai rouvert. Une fois que tout est chargé, aucune erreur et je n'ai pas eu à jouer avec le fichier tsconfig.json.

J'espère que cela t'aides

Je suis tombé sur ce même problème

  • supprimer l'espace de travail n'a pas aidé
  • changer forceConsistentCasingInFileNames n'a pas aidé

Pour mon cas, quelque part dans le répertoire, les erreurs se produisaient, a été changé ...? J'ai donc dû faire ce qui suit pour tous les réparer.

  1. Vous changez le nom du répertoire en quelque chose comme "OriginalDirectoryName" => "AnotherName"
  2. VsCode essaiera de mettre à jour le nom du répertoire dans la source, alors attendez quelques secondes, et il montrera que tous les fichiers doivent être mis à jour avec le nouveau nom de répertoire.
  3. Allez File -> Save Tous et enregistrez-les
  4. Changer le nom du répertoire "AnotherName" => "OriginalDirectoryName"
  5. Encore une fois, il va essayer de mettre à jour les fichiers, donc vous les enregistrez tous.
  6. Redémarrez VsCode.

alors il devrait résoudre le problème.

Je reçois ce bogue après avoir renommé un fichier de camelCase en majuscules toutes les premières lettres

Dans mon cas, j'avais l'habitude de créer un fichier nommé Logger mais changé en logger plus tard. Un fichier qui a importé cela affiche toujours ce message d'erreur, mais en fait dans le terminal ou d'autres fichiers, ne montrera pas ce message.

J'utilise donc la fonctionnalité VSCode Reload Window pour recharger le VSCode et le message d'erreur disparaît. Donc, je pense qu'il y a peut-être un cache quelque part dans VSCode pour cette erreur et n'a pas été effacé? Vous pouvez essayer si vous rencontrez ce problème après vous être assuré que le nom du fichier est correct.

J'ai le même problème, et je viens de découvrir que pour une raison quelconque, dans certains fichiers ts, il est appelé en utilisant une lettre majuscule, puis je l'ai renommé en minuscules et cela fonctionne.

Vous pouvez également essayer de supprimer ce fichier modèle ts et de le créer à nouveau avec angular-CLI.

La modification de la casse entraîne une exception sur la commande updateOpen. Notez comment le fichier est ouvert avec un cas différent et fermé avec le boîtier d'origine dans la même commande.

Info 69   [10:30:18.128] request:
    {"seq":5,"type":"request","command":"updateOpen","arguments":{"changedFiles":[],"closedFiles":["c:/temp/est/Logger.ts"],"openFiles":[{"file":"c:/temp/est/logger.ts","fileContent":"export class logger {\r\n    \r\n}","scriptKindName":"TS","projectRootPath":"c:\\temp\\est"}]}}
Err 70    [10:30:18.153] Exception on executing command {"seq":5,"type":"request","command":"updateOpen","arguments":{"changedFiles":[],"closedFiles":["c:/temp/est/Logger.ts"],"openFiles":[{"file":"c:/temp/est/logger.ts","fileContent":"export class logger {\r\n    \r\n}","scriptKindName":"TS","projectRootPath":"c:\\temp\\est"}]}}:

    Debug Failure. False expression: Script should not exist and not be open already

    Error: Debug Failure. False expression: Script should not exist and not be open already
        at ProjectService.applyChangesInOpenFiles (c:\Typescript\built\local\tsserver.js:138090:34)
        at Session.handlers.ts.createMapFromTemplate._a.(anonymous function) (c:\Typescript\built\local\tsserver.js:138972:46)
        at c:\Typescript\built\local\tsserver.js:140630:88
        at IOSession.Session.executeWithRequestId (c:\Typescript\built\local\tsserver.js:140621:28)
        at IOSession.Session.executeCommand (c:\Typescript\built\local\tsserver.js:140630:33)
        at IOSession.Session.onMessage (c:\Typescript\built\local\tsserver.js:140653:35)
        at Interface.<anonymous> (c:\Typescript\built\local\tsserver.js:141968:27)
        at Interface.emit (events.js:182:13)
        at Interface._onLine (readline.js:290:10)
        at Interface._normalWrite (readline.js:433:12)
        at Socket.ondata (readline.js:149:10)
        at Socket.emit (events.js:182:13)
        at addChunk (_stream_readable.js:283:12)
        at readableAddChunk (_stream_readable.js:264:11)
        at Socket.Readable.push (_stream_readable.js:219:10)
        at Pipe.onStreamRead [as onread] (internal/stream_base_commons.js:94:17)

Ce problème semble être plus complexe que la simple vérification des noms de fichiers racine. Lors de la réutilisation du programme, il y a un autre cas de test qui échoue qui est un simple test de réutilisation du programme:

it("forceConsistentCasingInFileNames works when renaming file with different casing", () => {
            const loggerFile: File = {
                path: `${projectRoot}/logger.ts`,
                content: `export class logger { }`
            };
            const anotherFile: File = {
                path: `${projectRoot}/another.ts`,
                content: `import { logger } from "./logger"; new logger();`
            };
            const tsconfig: File = {
                path: `${projectRoot}/tsconfig.json`,
                content: JSON.stringify({
                    compilerOptions: { forceConsistentCasingInFileNames: true }
                })
            };

            const host = createWatchedSystem([loggerFile, anotherFile, tsconfig, libFile, tsconfig]);
            createWatchOfConfigFile(tsconfig.path, host);
            checkOutputErrorsInitial(host, emptyArray);
            host.writeFile(anotherFile.path, anotherFile.content.replace("./logger", "./Logger"));
            host.runQueuedTimeoutCallbacks();
            checkOutputErrorsIncremental(host, [
                createCompilerDiagnostic(Diagnostics.File_name_0_differs_from_already_included_file_name_1_only_in_casing, loggerFile.path, `${projectRoot}/Logger.ts`),
            ]); // Currently the errors are not reported in watch mode but will be reported if program is created from scratch.
        });

Oui, j'ai ce même problème et aucun des correctifs / solutions de contournement précédemment mentionnés ne fait quoi que ce soit pour aider.

Dans mon cas, le message est:

error TS1149: File name '/mnt/c/Users/<username>/Documents/adobe-scripts/InDesign/Create Downloadable 
(2020a)/Illustrator/2015.3/index.d.ts' differs from already included file name '/mnt/c/Users/<username>/Documents/adobe-scripts/InDesign/Create Downloadable (2020a)/illustrator/2015.3/index.d.ts' only in casing.

@SturmB

Illustrateur

et

illustrateur

Je suis bien conscient du message d'erreur et de ce que voit le transpilateur. Ce que je ne comprends pas, c'est où se trouve la version minuscule de illustrator . J'ai fait plusieurs recherches et je ne trouve absolument aucune instance où le mot illustrator (lorsqu'il n'est pas utilisé dans un commentaire ou une chaîne ou autre) est tout en minuscules. La seule instance où je fais référence à ce fichier index.d.ts dans ce dossier Illustrator , le mot est correctement mis en majuscule, tout comme le nom du répertoire.

J'ai eu un problème similaire, mais je ne peux plus le reproduire. Cela ressemble à un bogue VSCode: un fichier avec un nom en majuscule est affiché en minuscule dans certains cas, y compris le menu de contrôle de source.

J'ai remarqué que, parfois, quelqu'un pouvait changer le nom d'un dossier de «foo» à «Foo» et lorsque vous faites un git pull il ne met pas à jour le nom du dossier ou quelqu'un oublie de pousser le changement . Dans ce cas, toutes vos références de code sont correctes, rien dans votre code n'est faux et souvent les fichiers de ce dossier peuvent être trouvés très bien; ça va juste faire paniquer TS.

Trouvez donc le dossier qui est la cause première. Modifiez le nom du dossier. Et commettez cela correctement:

git mv foo tmp
git mv tmp Foo

Suivi de commit et push serait le moyen le plus simple de renommer un répertoire dans un dépôt git.

Git a un paramètre de configuration qui lui indique s'il doit être sensible à la casse ou insensible: core.ignorecase . Pour dire à Git d'être sensible à la casse, définissez simplement ce paramètre sur false

En savoir plus:

https://stackoverflow.com/questions/17683458/how-do-i-commit-case-sensitive-only-filename-changes-in-git/17688308#17688308

ce que cela a fait pour moi est d'annuler tous les renommages, d'arrêter le serveur, de renommer tous les fichiers que je veux renommer et de redémarrer le serveur. Doit être une sorte de problème de mise en cache.

La fenêtre de rechargement dans VSCode a résolu le problème. J'ai changé un composant React en camelCase et j'ai rencontré le problème. Cela semble être une sorte de problème de mise en cache dans VSCode.

Je viens de rencontrer ça; mon componentA.tsx importé ../store/someStore mais cette importation a entraîné cette erreur, suggérant que le nom de fichier était SomeStore.ts (même si le système de fichiers et VSCode affichent un someStore.ts à cet emplacement .

Le nom de fichier '/mypath/store/someStore.ts' diffère du nom de fichier déjà inclus '/mypath/store/SomeStore.ts' uniquement par casse. _ts (1149) _

Il s'avère qu'un autre fichier ( ../store/index.ts ) avait une importation incorrecte ( ./SomeStore ) mais n'a pas généré d'erreur. Après avoir corrigé cette importation et redémarré VSCode, componentA.tsx ne lève plus cette erreur.

Le retour du correctif à index.ts et le redémarrage de VSCode entraînent à nouveau une erreur erronée sur componentA.tsx .

Une chose que j'ai faite pour améliorer ma situation a été d'arrêter d'utiliser WSL. Je suis revenu à ma configuration personnalisée d'origine qui exploite Cygwin et je n'ai pas eu ce problème depuis.

Je suis également confronté au même problème.
Pour l'instant, "résolu" en définissant:
"forceConsistentCasingInFileNames": false,
en tsconfig.json

Merci, ça aide

Après avoir fait quelques recherches sur Google, j'ai trouvé ceci . La dernière réponse a attiré mon attention. J'ai donc simplement fermé le dossier dans lequel travaillait dans Visual Studio Code et l'ai rouvert. Une fois que tout est chargé, aucune erreur et je n'ai pas eu à jouer avec le fichier tsconfig.json.

Cela a vraiment fonctionné

J'ai pu reproduire cela en définissant un nom de fichier, puis en le renommant en un autre. Il ne semble pas se mettre à jour correctement dans le mappage source. J'ai supprimé le fichier problématique et l'ai ajouté à nouveau. Une douleur, oui, mais ça a marché.

J'ai eu le problème, je l'ai résolu en définissant "forceConsistentCasingInFileNames": false
dans tsconfig.json puis à nouveau true.

Je répare uniquement le redémarrage de VSCode.

J'ai un problème similaire dans WebStorm après avoir changé les noms de fichiers, je suis tout à fait sûr qu'il s'agit d'un cache IDE.

Si la suppression du cache / le redémarrage de l'IDE ne vous aide pas, supprimez le dossier, clonez à nouveau le dépôt et effectuez une installation propre.

J'ai trouvé ceci sur un mac:

Scénario

  • fichier nommé ComponentA.ts
  • componentB.ts a import ComponentA from './ComponentA';
  • componentC.ts a aussi import ComponentA from './ComponentA';
  • changer le nom de fichier ComponentA.ts en componentA.ts
  • mettre à jour componentC.ts à import ComponentA from './componentA;'
  • oubliez de mettre à jour l'importation pour componentB.ts afin qu'il ait toujours l'ancien import ComponentA from './ComponentA;' majuscule

Erreur (à peu près):

 File name '/componentA.ts' differs from already included file name  '/ComponentA.ts'  only in casing. ts(1149)

Raison:

L'insensibilité à la casse sur Mac consiste à résoudre d'abord l'importation de restes import ComponentA from './ComponentA;' dans componentB.ts , puis à mettre en cache / enregistrer ce chemin d'importation.

Ensuite, l'importation correcte dans componentC.ts est erronée même si elle est correcte.

Comment y remédier:

  • trouver toutes les importations de componentA.ts / ComponentA.ts
  • vérifier la sensibilité à la casse et corriger.

Dans mon cas, le fichier d'erreur componentC.ts était en fait correct et j'ai dû corriger componentB.ts , même si le message indiquait un problème avec componentC.ts .

J'ai dû renommer mon fichier et gulp build. Ensuite, j'ai renommé l'ancien nom d'origine et cela s'est bien construit.

En raison d'un cache étrange qui ne couvre pas le cas de changement de nom du fichier vue et donc de plainte contre Vetur, j'ai dû recharger VS Code ( Ctrl + Shirt + P -> Recharger la fenêtre) comme @uniquexiaobai l'a conseillé.

Un redémarrage du Typescript-Server suffira. Le redémarrage du VSCode est excessif.

Dans VSC sur OSX: CMD + Shift + P suivi de la saisie de TypeScript: Restart TS server .

Avec webstorm Vous devez invalider et vider le cache:
fichier> invalider les caches / redémarrer

La solution la plus courte et la meilleure que j'ai trouvée est.

Supprimez simplement ce mot de celui qui cause des problèmes de boîtier.
par exemple
ListsDrawerOfContent et ListsDrawerofContent

J'ai supprimé du nom du fichier. Et les compilateurs l'ont compilé correctement.

Puis plus tard, j'ai renommé par mon cas souhaité ListsDrawerOfContent .
A fonctionné comme un charme.

Gardez également à l'esprit le git.

https://stackoverflow.com/questions/17683458/how-do-i-commit-case-sensitive-only-filename-changes-in-git

J'ai eu le même problème avec l'importation, après avoir renommé un fichier de "a" en "A", je viens de redémarrer le code vs et cela fonctionne.

J'ai eu le même problème. Redémarrage du VSCode et paramétrage de "forceConsistentCasingInFileNames": false ne peut pas m'aider.

info d'erreur: (diffèrent simplement par le symbole du disque)
Le nom de fichier 'D: /mycode/devmono2/packages/server-sdk/index.ts' diffère du nom de fichier déjà inclus 'd: /mycode/devmono2/packages/server-sdk/index.ts' uniquement dans casing.Vetur ( 1149)

Pourquoi?

Résolu!
Le mien était un problème simple.

Tout allait bien localement sur mac, mais j'obtenais cette erreur sur mon serveur Jenkins. Le problème était simplement que localement le nom du fichier était «quote.ts» mais dans mon dépôt git distant, c'était «Quote.ts».

Comment le problème est survenu
Donc, le nom de fichier était à l'origine «Quote.ts» que j'ai poussé vers le haut. J'ai ensuite changé pour 'quote.ts', mais git n'a pas vu cela comme un changement (je crois que les macs sont insensibles à la casse) - et par conséquent, le changement de cas n'a pas été reflété dans le repo distant.

Et donc, lorsque le pipeline Jenkins a été exécuté, il abaissait «Quote.ts» lorsqu'il était référencé comme «../../quote.ts» - ce qui entraînait l'erreur.

Comment je l'ai résolu

  1. Boire du café
  2. Modifier manuellement le nom de fichier dans le référentiel distant en minuscules
  3. git pull localement
  4. Exécuter le pipeline

Boom Bam! J'espère que cela aide quelqu'un

Eu un problème similaire qui a généré environ 100 de ces erreurs.

Je ne les ai pas tous lus de près car ils semblaient tous avoir le même problème de fond. J'étais récemment passé au nœud en cours d'exécution dans WSL2 que je tenais pour acquis était la cause du problème. Après 2 heures sans succès, j'ai parcouru toute la liste et trouvé un exemple où il y avait un bug réel.

import {FooInterface} de '../Foo'; // devrait être "../foo"
import {BarService} de '../Bar'; // devrait être "../bar"

Je l'ai changé en minuscules, rechargé vscode, reconstruit et toutes les erreurs ont disparu.

Ce que je pense, c'est que ts a essayé d'importer le chemin incorrect («Foo» au lieu de «foo»), puis a mis en cache le résultat et a essayé d'utiliser le chemin incorrect en cache lors du traitement du reste du code.

Espérons que cela aide quelqu'un là-bas!

Je viens de redémarrer mon ide puis l'erreur est partie

créez simplement un même objet dans le composant, et démarrez votre ng, après avoir exécuté avec succès, puis supprimez l'objet et importez votre lien,
alors ça devrait être du travail,
Dans mon projet, cela a fonctionné.

cela m'est juste arrivé, c'est un problème permanent qui n'a pas été résolu. Cela se produit chaque fois que je change la casse d'un nom de répertoire et que j'essaie de valider le changement. Git ne reconnaît pas le changement de casse pour un nom de répertoire.

+1 ...... mais WHYYYYYYYY

J'ai juste fait face au problème. Il s'est avéré que lorsque j'ai essayé de l'importer à l'aide de vscode, VSCode a utilisé le nom de fichier et le nom de répertoire précédents. Je l'ai donc modifié et après avoir exécuté tsc il n'a montré aucune erreur dans le terminal, mais j'obtenais toujours cette ligne ondulée lue dans VSCode. J'ai donc redémarré le serveur Typescript dans vscode ( Typescript: Restart TS Server ) et il est parti. J'espère que ça aide quelqu'un.

@ninjavang vous m'avez aidé! J'ai eu le même problème avec mon pipeline gitlab ci / cd. Il s'avère que lorsque je suis allé à la succursale distante et que j'ai vérifié le chemin du fichier, il y avait deux versions du fichier, chacune dans sa version sensible à la casse.

J'ai supprimé la version indésirable sur la télécommande, copié le fichier localement, abaissé la télécommande, actualisé mon code VS et rajouté le fichier. Ça a marché!

Merci pour l'aide!

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