Extended - pour fournir plus de détails en fonction de certains commentaires
L'erreur
Erreur TS2306: le fichier 'test.ts' n'est pas un module.
Provient du fait décrit ici http://exploringjs.com/es6/ch_modules.html
17. Modules
Ce chapitre explique le fonctionnement des modules intégrés dans ECMAScript 6.
17.1 Aperçu
Dans ECMAScript 6, les modules sont stockés dans des fichiers. Il y a exactement un module par fichier et un fichier par module. Vous avez deux façons d'exporter des choses à partir d'un module. Ces deux méthodes peuvent être mélangées, mais il est généralement préférable de les utiliser séparément.
17.1.1 Exportations nommées multiples
Il peut y avoir plusieurs exportations nommées:
//------ lib.js ------
export const sqrt = Math.sqrt;
export function square(x) {
return x * x;
}
export function diag(x, y) {
return sqrt(square(x) + square(y));
}
...
17.1.2 Exportation par défaut unique
Il peut y avoir une seule exportation par défaut. Par exemple, une fonction:
//------ myFunc.js ------
export default function () { ··· } // no semicolon!
Sur la base de ce qui précède, nous avons besoin du export
, dans le cadre du fichier test.js. Ajustez-en le contenu comme ceci:
// test.js - exporting es6
export module App {
export class SomeClass {
getName(): string {
return 'name';
}
}
export class OtherClass {
getName(): string {
return 'name';
}
}
}
Et maintenant, nous pouvons l'importer de trois manières:
import * as app1 from "./test";
import app2 = require("./test");
import {App} from "./test";
Et nous pouvons consommer des trucs importés comme ceci:
var a1: app1.App.SomeClass = new app1.App.SomeClass();
var a2: app1.App.OtherClass = new app1.App.OtherClass();
var b1: app2.App.SomeClass = new app2.App.SomeClass();
var b2: app2.App.OtherClass = new app2.App.OtherClass();
var c1: App.SomeClass = new App.SomeClass();
var c2: App.OtherClass = new App.OtherClass();
et appelez la méthode pour la voir en action:
console.log(a1.getName())
console.log(a2.getName())
console.log(b1.getName())
console.log(b2.getName())
console.log(c1.getName())
console.log(c2.getName())
La partie d'origine essaie de réduire la complexité de l'utilisation de l'espace de noms
Pièce d'origine:
Je suggérerais vraiment fortement de vérifier ces questions et réponses:
Permettez-moi de citer la première phrase:
N'utilisez pas d '"espaces de noms" dans les modules externes.
Ne fais pas ça.
Sérieusement. Arrêtez.
...
Dans ce cas, nous n'avons tout simplement pas besoin de l' module
intérieur de test.ts
. Cela pourrait être le contenu de celui-ci ajusté test.ts
:
export class SomeClass
{
getName(): string
{
return 'name';
}
}
En savoir plus ici
Dans l'exemple précédent, lorsque nous avons consommé chaque validateur, chaque module n'a exporté qu'une seule valeur. Dans de tels cas, il est fastidieux de travailler avec ces symboles via leur nom qualifié alors qu'un seul identifiant ferait tout aussi bien l'affaire.
La export =
syntaxe spécifie un seul objet qui est exporté à partir du module . Cela peut être une classe, une interface, un module, une fonction ou une énumération. Lors de l'importation, le symbole exporté est consommé directement et n'est qualifié par aucun nom.
nous pouvons le consommer plus tard comme ceci:
import App = require('./test');
var sc: App.SomeClass = new App.SomeClass();
sc.getName();
En savoir plus ici:
Dans certains cas, vous souhaiterez peut-être charger un module uniquement sous certaines conditions. Dans TypeScript, nous pouvons utiliser le modèle illustré ci-dessous pour implémenter cela et d'autres scénarios de chargement avancés pour appeler directement les chargeurs de module sans perdre la sécurité de type.
Le compilateur détecte si chaque module est utilisé dans le JavaScript émis. Pour les modules qui ne sont utilisés que dans le cadre du système de types, aucun appel obligatoire n'est émis. Cette élimination des références inutilisées est une bonne optimisation des performances et permet également le chargement facultatif de ces modules.
L'idée centrale du modèle est que l'instruction import id = require ('...') nous donne accès aux types exposés par le module externe. Le chargeur de module est appelé (via require) dynamiquement, comme indiqué dans les blocs if ci-dessous. Cela exploite l'optimisation de la sélection des références afin que le module ne soit chargé qu'en cas de besoin. Pour que ce modèle fonctionne, il est important que le symbole défini via l'importation ne soit utilisé que dans les positions de type (c'est-à-dire jamais dans une position qui serait émise dans le JavaScript).