Le message d'erreur doit être plus clair. au lieu de namespaces il peut dire non-module . Recommandations @DanielRosenwasser ?

Il ne doit pas y avoir de message d'erreur dans cette situation. L'option --isolatedModules devrait simplement désactiver complètement le système de module interne, si tsc continue de faire des erreurs de cette façon, l'option n'a pas fait son travail.

Dans # 15839, j'avais l'intention de modifier le comportement de la vérification, mais j'ai réalisé plus tard que cette vérification était tout simplement inutile et que la solution idéale est de la supprimer.
Typescript a toujours autorisé l'utilisation de l'espace de noms dans un module externe avec --isolatedModules sur:

export function something() {} // export found, so this module is considered 'external'
namespace ns {} // namespace is still valid in an external module

Ainsi, le chèque ne fait rien dans ce cas (apparemment invalide), alors qu'il est censé se plaindre. Alors pourquoi se plaindre quand le programmeur n'utilise même pas d'espace de noms, ne fait rien de mal?

@wilonth La raison de ce problème est que le message d'erreur est erroné: les espaces de noms conviennent parfaitement s'ils font partie d'un module (es6), mais tout fichier non-module doit être une erreur.

@ andy-ms J'essayais de souligner que tout le code pour vérifier cette erreur est tout simplement inutile, et nous devrions simplement le supprimer au lieu de compliquer davantage le code.
Mon point est que lorsque --isolatedModules est activé, chaque fichier doit être considéré comme un module externe (ES6), point final. En ce sens, l'utilisation des espaces de noms devrait être légale car pour le moment, il est parfaitement légal d'utiliser des espaces de noms dans les modules ES6 (avec --isolatedModules activé).

Mon point est que lorsque --isolatedModules est activé, chaque fichier doit être considéré comme un module externe (ES6), point final.

La sémantique ici est qu'un module est un fichier avec au moins une importation ou une exportation de niveau supérieur. peu importe comment vous invoquez le compilateur.

@mhegazy Oui et cette règle est exactement la racine du problème que nous avons ici. La règle traite injustement un fichier sans importation ni exportation comme faisant partie du système de module interne hérité, donc --isolatedModules rejette le fichier.
Maintenant, nous ne devrions pas changer la règle car cela cassera probablement beaucoup de choses, mais nous pouvons résoudre le problème actuel très facilement en supprimant simplement ce message d'erreur.
Imaginons que ce message d'erreur "impossible de compiler les espaces de noms" soit supprimé, qu'est-ce qui pourrait mal tourner? Qu'en est-il d'une base de code qui utilise un module interne, comme le compilateur Typescript lui-même? Avec --isolatedModules activé, cela compilerait-il en code garbage et dérouterait l'utilisateur? Non, ce ne sera pas le cas, il y aurait beaucoup de messages d'erreur Typescript concernant des symboles non définis, car --isolatedModules rompu les liens entre les fichiers, ce qui est assez évident à comprendre.
Pouvez-vous trouver des inconvénients à supprimer ce message d'erreur? Je ne pourrais pas. Pourquoi ne choisirions-nous pas la solution la plus simple, qui n'implique aucun travail (il suffit de supprimer les lignes) et qui n'a aucun inconvénient?

Avec --isolatedModules activé, cela compilerait-il en code de garbage et dérouterait l'utilisateur? Non ce ne sera pas

Oui, il sera.

Le but de l'indicateur --isolatedModules est de valider qu'un programme peut être compilé avec succès par transpilation d'un seul fichier.

La base de code TypeScript ne peut pas être compilée avec succès via une transpilation de fichier unique. Il y a du code comme celui-ci partout:

fichier1

namespace ts {
  export var x = 10;
}

fichier2

namespace ts {
  var y = x; // transpiles to ts.x during whole-program compilation
}

Si nous transpilions fichier2 à un seul fichier, il se briserait.

Mon mal, j'ai foiré mes tests. Je retire ma proposition par la présente. Merci @RyanCavanaugh pour ce rappel.

La solution devrait donc être: détecter l'utilisation réelle de l'espace de noms avant de lancer ce message d'erreur (c'est-à-dire la solution «alternative» proposée par @ andy-ms). Nous ne pouvons pas simplement changer le texte en autre chose car un message d'erreur dans ce cas est totalement faux.
Je veux faire un PR, mais puis-je toujours avoir confiance ici après avoir craché toutes ces conneries?

A global file cannot be compiled using '--isolatedModules'. Ensure your file contains imports, exports, or an 'export {}' statement.

Si nous transpilions fichier2 à un seul fichier, il se briserait.

Désolé pour la nécromancie, mais cela devrait sûrement, lors du ciblage de modules, échouer avec quelque chose comme 'x' is not defined ? Ce cas ne me semble pas différent du trivial:

fichier1

var x = 10;

fichier2

var y = x;

Ce qui fonctionne également lors de la concaténation / évaluation globale et non avec des modules; rien à voir avec namespaces .

Essentiellement, pourquoi dactylographié se donne-t-il la peine de deviner que les fichiers sans import ou export ne sont pas des modules, alors qu'il devrait déjà savoir à partir de l'option du compilateur module ? Par exemple, Typescript se compile sans paramétrer module , donc il utilise la valeur par défaut none , donc le compilateur peut assumer la concaténation / l'évaluation globale.

Lorsque vous utilisez --module <something> et que vous utilisez des déclarations non importées à partir d'autres fichiers, (y compris les espaces de noms eux-mêmes), le typographie échouera déjà avec "non défini" avant --isolatedModules , et de même après avec le export {} solution

J'ai remarqué que pour une raison quelconque, vous pouvez toujours utiliser import / export avec --module none --isolatedModules , ce qui est plutôt déroutant, peut-être un bug?

@DanielRosenwasser en tant qu'utilisateur final: que signifie "Un fichier global"? J'aime les conseils cependant. Peut-être plus comme "Les fichiers sans aucune instruction d'importation ou d'exportation ne sont pas des modules et ne peuvent pas être compilés avec '--isolatedModules'. Ajoutez une instruction 'export {}' si ce fichier n'est évalué que pour ses effets secondaires." - bien que la langue ne semble pas très message d'erreur-y.

Je vois la même erreur pour un simple projet js. Je viens de créer un exemple de projet js ci-dessous sont le contenu des fichiers de package et de script. Comment puis-je résoudre ce problème?

Package.json
{
"plnkr": {
"runtime": "système"
}
}

lib / script.js
//
// Blackjack
// par Dheeraj Kumar
//

let card1 = "As de pique",
card2 = "dix de coeurs";

console.log ('Bienvenue au Blackjack!');

console.log ("Vous êtes distribué:");
conosle.log ("" + carte1);
console.log ("" + carte2);

Des mises à jour à ce sujet?

Je me retrouve souvent à faire cela dans de petits tests.

describe('jest', () => {
  it('finds this test', () => {
    expect(true).toBeTruthy();
  });

  it('parses this typescript', () => {
    const actual: number = 0;
    const expected: number = 0;
    expect(actual).toEqual(expected);
  });
});

export {
  // Use an empty export to please Babel's single file emit.
  // https://github.com/Microsoft/TypeScript/issues/15230
}

Je veux vraiment une option qui oblige TypeScript à considérer chaque fichier .ts comme un module ES6, qu'il contienne ou non des instructions d'importation / exportation. J'ai initialement supposé que l'option --isolatedModules était cette option, mais cela provoque cette erreur extrêmement déroutante sur les fichiers sans importation / exportation. (Je ne comprends toujours pas ce que le message d'erreur signifie par les espaces de noms. Je ne pense pas que j'utilise cette fonctionnalité.) La raison pour laquelle je veux ce paramètre est que j'ai eu plusieurs problèmes qui n'ont pas été détectés par TypeScript parce que j'ai accidentellement référencé une variable de niveau supérieur d'un fichier .ts dans un autre (qui n'avaient pas d'instructions d'importation / exportation, donc TypeScript ne les a pas traités comme des modules ES6) malgré l'utilisation de node / parcel / webpack où les fichiers ne peuvent pas se référencer variables non exportées comme ça.

Je me suis retrouvé ici en essayant de réparer une sorte de gêne liée. Les commentaires ci-dessous sont juste pour aider tous les autres utilisateurs de VS Code recherchant cette erreur avec create-react-app et TypeScript.

Lors de la configuration d'un proxy avec create-react-app 2.x et TypeScript, vous ajoutez un fichier nommé setupProxy.js avec un code comme celui-ci:

const proxy = require('http-proxy-middleware');
module.exports = function(app) { /* ... */ };

react-scripts lit ce fichier en dehors du processus de transpilation ts, il doit donc être purement js.

Cela fonctionne exactement comme documenté , mais cela a un effet secondaire ennuyeux.

Le tsconfig.json généré par react-scripts inclut tous les fichiers de src , y compris setupProxy.js . En conséquence, il déclenche VS Code pour afficher l'erreur Cannot compile namespaces... dans setupProxy.js , marquer le code avec un gribouillage rouge et l'inclure dans le volet Problèmes. Dans ma configuration, il met également en évidence le fichier et tous ses dossiers ancêtres en rouge.

Solution: supprimez le message d'erreur VS Code en excluant le fichier setupProxy.js dans tsconfig.json.

{
  // ...
  "exclude": ["src/setupProxy.js"]
}

react-scripts force isolatedModules: true , mais cela ne semble pas écraser exclude .

Alternative: ajoutez une exportation nommée à `setupProxy.js:

export const _ = '';

Avec une exportation de premier niveau, elle est désormais valide avec --isolatedModules.

Très souvent, les développeurs reçoivent ce message car il y a des fichiers qui ne devraient pas être inclus dans la copliation (gulp.js, etc.)

ATTENTION - Si vous utilisez une application create-react et que vous voyez ce problème comme moi ... j'ai pu contourner cela en modifiant mon fichier tsconfig.json ....

Changer les éléments suivants

    "isolatedModules": true,

à

    "isolatedModules": false,

@UncleFifi Et puis l'erreur passe de la vérification de type à la transformation dactylographiée Babel, voir la première mise en garde .

@jtbennett vous ne pouvez rien exporter du tout avec export {}; - la forme dégénérée de export { name, localName as exportName };

@UncleFifi Et puis l'erreur passe de la vérification de type à la transformation dactylographiée Babel, voir la première mise en garde .

Seulement si vous utilisez réellement des espaces de noms. Ce problème concerne principalement cette erreur se plaignant des espaces de noms lorsque vous n'utilisez même pas d'espaces de noms et que vous avez simplement un fichier légal avec import / export.

Seulement si vous utilisez réellement des espaces de noms. Ce problème concerne principalement cette erreur se plaignant des espaces de noms lorsque vous n'utilisez même pas d'espaces de noms et que vous avez simplement un fichier légal avec import / export.

Bon, désolé - ça fait un moment que je n'ai pas lu ce fil! Cela dit, la raison pour laquelle ils définissent --isolatedModules dans CRA est parce qu'il émule étroitement les limites de babel dactylographié (puisque babel est également une transpilation à un seul fichier), vous devez donc au moins être conscient que vous supprimez cette garde- rail.

Donc, la solution actuelle à l'erreur Cannot compile namespaces when --isolatedModules flag is provided consiste-t-elle à ajouter export {}; en haut du fichier?

Oui, cela contournera le problème. (En supposant que vous n'utilisez pas réellement TypeScript namespace . Sinon, vous avez un problème différent et probablement légitime.)

Je viens de rencontrer ce message en raison d'un fichier un fichier "vide" (c'est-à-dire que le fichier entier a été commenté). Je suis heureux que TS ait attrapé cela, mais le message d'erreur était extrêmement opaque (et les couleurs étaient cassées sur une installation CentOS 7 vanille, mais cela est probablement dû au serveur de développement Webpack, non lié directement à TS)

_Edit: impossible de se reproduire. Je regardais définitivement le fichier composé de seulement trois exportations de haut niveau et j'ai eu cette erreur, mais j'ai fait quelque chose de mal ailleurs.

Cette erreur m'est arrivée avec un fichier qui contient des exportations de niveau supérieur.

// Cannot compile namespaces:
export const foo = 'foo';

// Compiles fine
const foo = 'foo';
export { foo };

@ denis-sokolov Question évidente: avez-vous également d'autres éléments dans ce fichier, tels que des espaces de noms?

Si c'est littéralement juste le export const , ma deuxième hypothèse serait que le dactylographié est utilisé dans quelque chose comme webpack avec ts-loader, et ne voit que le contenu après le passage précédent (par exemple babel-loader) qui se développe export d'une certaine manière, mais c'est un peu exagéré.

Je suis incapable de le reproduire plus. Désolé, @simonbuchan , pour la fausse alerte.

Je ne sais pas pourquoi j'obtiens cette erreur sur ce fichier spécifique.
Les autres fichiers se comportent bien

Je suis dans une situation où j'utilise CRA TypeScript et j'importe un package qui n'a pas de @types . Je veux ajouter un declare module 'package' pour fournir mes propres types, mais je ne peux mettre cette instruction dans aucun fichier de module. Je vais donc créer types.ts pour y placer le relevé declare module . Maintenant, j'obtiens cette erreur.

Lorsque je remplace isolatedModules par false , l'ARC le modifie à ma place. Ce n'est pas une solution.

Lorsque j'ajoute export {} au fichier types.ts avec declare module , j'obtiens un nom de module invalide dans l'augmentation. au lieu. Cette erreur est évitée en plaçant la déclaration dans un fichier non-module, mais CRA via ce paramètre forcé isolatedModules force chaque fichier à être un module!

Il y a donc un chemin circulaire pour résoudre une erreur uniquement pour atterrir sur une autre et inversement. Comment cela peut-il être résolu?

@Bnaya à une supposition, les fichiers qui fonctionnent utilisent des instructions d'importation ou d'exportation? N'utilisez que l'un des require()/module.exports et import/export dans votre code. Sinon, vérifiez que tous vos fichiers sont couverts par l'inclusion tsconfig (consultez la documentation pour plus de détails à ce sujet

Les déclarations du module
Je n'ai eu que les paramètres de réajout de l'ARC que j'ai supprimés, je ne les ai pas modifiés, mais c'est peut-être plus insistant pour les modules isolés?

@simonbuchan J'ai essayé un .d.ts mais cela n'a pas fonctionné pour moi non plus, je vais vous expliquer pourquoi exactement, pas sûr de ce que c'était. Et en effet, l'ARC a réécrit ce paramètre pour moi.

@simonbuchan j'ai essayé tout ce qui précède avant la main - en vain :(

@simonbuchan Hmm ok donc .d.ts fonctionne, je peux y déclarer le module et le taper. La raison pour laquelle je l'ai initialement abandonné est que pour les types que je souhaite déclarer dans ce module, je dois faire référence à d'autres types, mais l'introduction de import dans le fichier .d.ts le fait cesser de fonctionner. Je ne sais pas comment résoudre cela, mais c'est mon manque de connaissance de TypeScript qui n'a plus rien à voir avec cette erreur.

Voici un cas de repro minimal, en utilisant typescript @ next (repo complet sur https://github.com/yang/sandbox-ts-namespaces-error):

src / a.js: (attention, aucun mot-clé import / export nécessaire)

module.exports = "hello"; // you could really put anything here, e.g. console.log('hello');

tsconfig.js:

{
  "compilerOptions": {
    "allowJs": true,
    "isolatedModules": true,
    "noEmit": true,
    "strict": true
  },
  "include": ["src"]
}

Erreur:

$ ./node_modules/.bin/tsc
src/a.js:1:1 - error TS1208: Cannot compile namespaces when the '--isolatedModules' flag is provided.

1 module.exports = "hello";
  ~~~~~~


Found 1 error.

Moi aussi, j'ai rencontré cela pour la première fois via create-react-app --typescript , qui vous demande de créer un setupProxy.js (ou setupTests.js). L'ARC définit également isolatedModules et allowJs sur true. Cela ne semble pas avoir été un problème jusqu'à une version plus récente de type script (je n'ai pas vu d'erreurs sur setupProxy.js sur typescript 3.1.x, uniquement après la mise à jour vers 3.2.x ou 3.3.x).

La solution de contournement de l'ajout de fichiers .js à votre jeu d'exclusion fonctionne lors de l'exécution de tsc, mais - ennuyeusement - vous voyez toujours des erreurs de ces fichiers dans les éditeurs du service de langage TS (essayé à la fois VS Code et Webstorm). (Cela semble être un problème distinct et plus général avec le service de langage TS ne respectant pas les exclusions - mais je n'ai pas pu trouver un problème existant pour cela.) Pour masquer cette erreur dans les éditeurs, j'ai ajouté des fichiers .d.ts pour les fichiers * .js.

En outre, exiger ou importer les fichiers .js rend également l'exclusion inefficace, provoquant le déclenchement de l'erreur (en dehors de votre éditeur).

Seule la désactivation de allowJs (contre ce que suggère create-react-app) semble fonctionner pour moi.

Je reçois toujours cette erreur pour mon travailleur Web.

J'ai essayé d'exclure le fichier ou le dossier individuel et cela ne fonctionne pas pour moi.

N'existe-t-il aucun moyen de remplacer ce paramètre isolatedModules, CRA continue de réécrire le tsconfig.json.

D'autres suggestions?

@jamespfarrell Mettez export {}; quelque part dans votre fichier.

@Macil merci pour vos conseils.

J'obtiens cette erreur:

Tentative d’erreur d’importation: «./workers/HeartBeat.worker.js» ne contient pas d’exportation par défaut (importée en tant que «HeartBeatWorker»).

Si j'ajoute:

export default {};

Je reçois:

Uncaught TypeError: _workers_HeartBeat_worker_js__WEBPACK_IMPORTED_MODULE_2 __. Default n'est pas un constructeur

N'y a-t-il pas simplement un moyen de contourner ces «modules isolés» si ce n'est pour un fichier, même pour tous les fichiers?

Ces erreurs que vous obtenez maintenant ne sont pas liées au paramètre isolatedModules. Si vous avez désactivé isolatedModules, vous obtiendrez toujours ces erreurs.

Tentative d’erreur d’importation: «./workers/HeartBeat.worker.js» ne contient pas d’exportation par défaut (importée en tant que «HeartBeatWorker»).

Où cette erreur se produit-elle? On dirait que vous essayez d'importer l'exportation par défaut d'un fichier qui n'en a pas, comme import Foo from './workers/HeartBeat.worker.js'; . Si vous ne souhaitez pas importer une exportation par défaut, modifiez votre ligne d'importation en import './workers/HeartBeat.worker.js'; .

Vous avez raison, c'était autre chose @Macil ! Merci!

_Peut-être que quelqu'un d'autre aura le même problème: _ J'ai eu la même erreur apparaissant pour quelques fichiers que j'ai laissés comme espaces réservés sans contenu, mais je les ai importés dans d'autres fichiers, c'est-à-dire. J'avais un fichier styles.js vide qui a été importé dans un autre fichier de composant.

Ajoutez simplement

J'ai eu cette erreur pour une définition de module que j'ai accidentellement suffixée .ts au lieu de .d.ts , si quelqu'un d'autre fait cette erreur particulière. Vous devez redémarrer le serveur après la fixation.

Même erreur. J'utilise l'ARC

Face à ce problème sur l'ARC. J'ai simplement oublié d'exporter quoi que ce soit du fichier:

J'ai donc eu cette erreur car j'avais un fichier .js dans le dossier racine de mon projet, dans mon fichier tsconfig.json j'avais configuré ceci:

"compilerOptions": {
    ....
  },
  "include": ["src"],

J'ai dû le changer pour ça:

"compilerOptions": {
    ....
  },
  "include": ["src/*"],

Cela a réglé le problème, mais je ne comprends pas pourquoi, quelqu'un peut-il me l'expliquer? Ma compréhension était que l'inclusion de src éliminerait les fichiers racine et les dossiers frères.

@thitemple Avez-vous obtenu cet extrait / * d'un article quelque part? Le manuel Webpack semble indiquer que le premier est le bon. Je diagnostique un problème similaire et suis tombé sur votre message.

@ vort3xxx Je ne l'ai pas fait. J'ai vu ce post https://github.com/microsoft/TypeScript/issues/15230#issuecomment -479730947 de @DaviSpindola et l'

@ vort3xxx Je ne l'ai pas fait. J'ai vu ce post # 15230 (commentaire) de @DaviSpindola et l'

Même problème, même solution. TS 3.5.2.

@ThomasdenH

@simonbuchan J'ai essayé un .d.ts mais cela n'a pas fonctionné pour moi non plus, je vais vous expliquer pourquoi exactement, pas sûr de ce que c'était. Et en effet, l'ARC a réécrit ce paramètre pour moi.

Rencontrer exactement le même problème. Avez-vous déjà trouvé comment résoudre ce problème? La définition des fichiers de déclaration .ts ou .d.ts à l'intérieur d'une application create react renvoie l'erreur All files must be modules when the '--isolatedModules indicateur est fourni. Définir l'indicateur sur false ou supprimer la propriété isolatedModules réinitialise entièrement à true lors du démarrage de l'application create react.
L'ajout de export {} au bas du fichier de déclaration entraîne l'erreur: Invalid module name in augmentation. Module '...' resolves to an untyped module at '...' .

Quelqu'un s'il vous plaît aider. Comment ajouter des fichiers de déclaration personnalisés à un projet d'application Create React?

Je viens de comprendre si quelqu'un d'autre a le même problème. Ajoutez simplement vos types de déclaration au fichier react-app-env.d.ts dans le dossier source lors de l'utilisation de l'application create react.