Wie verwende ich Namespaces mit externen TypeScript-Modulen?

Nichts ist falsch mit Ryans Antwort, aber für die Leute, die hierher kamen und nach einer one-class-per-file-Struktur suchten, während sie noch korrekt ES6-Namespaces verwenden, lesen Sie bitte die hilfreiche Ressource this von Microsoft .

Unklar ist mir nach dem Lesen des Dokuments: Wie importiere ich das gesamte (zusammengeführte) Modul mit singleimport?.

Edit Zurückkehren, um diese Antwort zu aktualisieren. In TS gibt es einige Ansätze zum Namensraum. 

Alle Modulklassen in einer Datei. 

export namespace Shapes {
    export class Triangle {}
    export class Square {}      
}

Importieren Sie Dateien in den Namespace und weisen Sie sie erneut zu

import { Triangle as _Triangle } from './triangle';
import { Square as _Square } from './square';

export namespace Shapes {
  export const Triangle = _Triangle;
  export const Square = _Square;
}

Fässer

// ./shapes/index.ts
export { Triangle } from './triangle';
export { Square } from './square';

// in importing file:
import * as Shapes from './shapes/index.ts';
// by node module convention, you can ignore '/index.ts':
import * as Shapes from './shapes';
let myTriangle = new Shapes.Triangle();

Eine abschließende Überlegung. Sie könnten für jede Datei Namespace sein

// triangle.ts
export namespace Shapes {
    export class Triangle {}
}

// square.ts
export namespace Shapes {
    export class Square {}
}

Wenn jedoch zwei Klassen aus demselben Namensraum importiert werden, wird TS sich darüber beklagen, dass es einen doppelten Bezeichner gibt. Die einzige Lösung, wie diesmal der Fall ist, ist der Aliasname des Namespaces.

import { Shapes } from './square';
import { Shapes as _Shapes } from './triangle';

// ugh
let myTriangle = new _Shapes.Shapes.Triangle();

Dieses Aliasing ist absolut abscheulich, also mach es nicht. Sie sind besser mit einem Ansatz oben. Ich persönlich bevorzuge das "Fass".

Versuchen Sie, nach Ordnern zu organisieren:

baseTypes.ts

export class Animal {
    move() { /* ... */ }
}

export class Plant {
    photosynthesize() { /* ... */ }
}

dog.ts

import b = require('./baseTypes');

export class Dog extends b.Animal {
    woof() { }
}   

tree.ts

import b = require('./baseTypes');

class Tree extends b.Plant {
}

LivingThings.ts

import dog = require('./dog')
import tree = require('./tree')

export = {
    dog: dog,
    tree: tree
}

main.ts

import LivingThings = require('./LivingThings');
console.log(LivingThings.Tree)
console.log(LivingThings.Dog)

Die Idee ist, dass es Ihrem Modul selbst egal sein sollte, dass es an einem Namespace teilnimmt. Dies macht jedoch die API für den Konsumenten auf eine kompakte, vernünftige Art und Weise zugänglich, die unabhängig von dem Typ des für das Projekt verwendeten Modulsystems ist. 

Kleine Verbesserung der Antwort von Albino Frenchy:

base.ts

export class Animal {
move() { /* ... */ }
}

export class Plant {
  photosynthesize() { /* ... */ }
}

dog.ts

import * as b from './base';

export class Dog extends b.Animal {
   woof() { }
} 

things.ts

import { Dog } from './dog'

namespace things {
  export const dog = Dog;
}

export = things;

main.ts

import * as things from './things';

console.log(things.dog);

OP Ich bin mit dir, Mann .. Auch diesmal ist mit 300+ Stimmen nichts falsch, aber meine Meinung ist:

1. was ist falsch daran, Klassen einzeln in ihre gemütlichen warmen Dateien zu legen? Ich meine, das wird die Dinge viel besser aussehen lassen, oder? (oder jemand wie eine 1000-Zeilen-Datei für alle Modelle)

2. wenn also die erste erreicht wird, müssen wir import import importieren ... importieren Sie einfach jede der Modelldateien wie man, srsly, eine Modelldatei, eine .d.ts-Datei. Warum gibt es so viele * ist da drin? es sollte einfach und aufgeräumt sein, und das ist es. Warum brauche ich dort Importe? Warum? C # hat aus einem bestimmten Grund Namespaces.

3. Bis dahin verwenden Sie buchstäblich "filenames.ts" als Bezeichner. Als Identifikatoren ... Kommt ihr 2017 jetzt und wir machen das immer noch? Ich gehe zurück zum Mars und schlafe noch 1000 Jahre.

Leider lautet meine Antwort: nop, Sie können die Sache mit dem Namensraum nicht funktional machen, wenn Sie nicht alle diese Importe verwenden oder diese Dateinamen als Bezeichner verwenden (was ich wirklich dumm finde). Eine weitere Option ist: alle diese Abhängigkeiten in eine Box namens filenameasidentifier.ts aufnehmen und verwenden 

export namespace(or module) boxInBox {} .

wickeln Sie sie so ein, dass sie nicht versuchen, auf andere Klassen mit demselben Namen zuzugreifen, wenn sie einfach nur versuchen, eine Referenz von der Klasse zu erhalten, die direkt über ihnen sitzt.

Einige der Fragen/Kommentare, die ich zu diesem Thema gesehen habe, klingen für mich so, als ob die Person Namespace verwendet, wobei sie "Modul-Alias" bedeutet. Wie Ryan Cavanaugh in einem seiner Kommentare erwähnt hat, können Sie mit einem Wrapper-Modul mehrere Module erneut exportieren.

Wenn Sie wirklich alles aus demselben Modulnamen/-alias importieren möchten, kombinieren Sie ein Wrapper-Modul mit einer Pfadzuordnung in Ihrem tsconfig.json.

Beispiel:

./path/to/CompanyName.Products/Foo.ts

export class Foo {
    ...
}

./path/to/CompanyName.Products/Bar.ts

export class Bar {
    ...
}

./path/to/CompanyName.Products/index.ts

export { Foo } from './Foo';
export { Bar } from './Bar';

tsconfig.json

{
    "compilerOptions": {
        ...
        paths: {
            ...
            "CompanyName.Products": ["./path/to/CompanyName.Products/index"],
            ...
        }
        ...
    }
    ...
}

main.ts

import { Foo, Bar } from 'CompanyName.Products'

Hinweis : Die Modulauflösung in den .js-Ausgabedateien muss irgendwie behandelt werden, z. B. mit diesem https: // github. com/tleunen/babel-plugin-module-resolver

Beispiel .babelrc für die Aliasauflösung:

{
    "plugins": [
        [ "module-resolver", {
            "cwd": "babelrc",
            "alias": {
                "CompanyName.Products": "./path/to/TypeScript/build/output/CompanyName.Products/index.js"
            }
        }],
        ... other plugins ...
    ]
}

Versuchen Sie dieses Namespaces-Modul

namespaceModuleFile.ts

export namespace Bookname{
export class Snows{
    name:any;
    constructor(bookname){
        console.log(bookname);
    }
}
export class Adventure{
    name:any;
    constructor(bookname){
        console.log(bookname);
    }
}
}





export namespace TreeList{
export class MangoTree{
    name:any;
    constructor(treeName){
        console.log(treeName);
    }
}
export class GuvavaTree{
    name:any;
    constructor(treeName){
        console.log(treeName);
    }
}
}

bookTreeCombine.ts

--- Zusammenstellungsteil ---

import {Bookname , TreeList} from './namespaceModule';
import b = require('./namespaceModule');
let BooknameLists = new Bookname.Adventure('Pirate treasure');
BooknameLists = new Bookname.Snows('ways to write a book'); 
const TreeLis = new TreeList.MangoTree('trees present in nature');
const TreeLists = new TreeList.GuvavaTree('trees are the celebraties');

Der richtige Weg, um Ihren Code zu organisieren, besteht darin, anstelle von Namespaces separate Verzeichnisse zu verwenden. Jede Klasse befindet sich in einer eigenen Datei, im jeweiligen Namespace-Ordner. index.ts exportiert nur jede Datei erneut. In der Datei index.ts sollte sich kein tatsächlicher Code befinden. Wenn Sie Ihren Code so organisieren, ist die Navigation viel einfacher und er ist selbstdokumentierend, basierend auf der Verzeichnisstruktur.

// index.ts
import * as greeter from './greeter';
import * as somethingElse from './somethingElse';

export {greeter, somethingElse};

// greeter/index.ts
export * from './greetings.js';
...

// greeter/greetings.ts
export const helloWorld = "Hello World";

Sie würden es dann als solches verwenden:

import { greeter } from 'your-package'; //Import it like normal, be it from an NPM module or from a directory.
// You can also use the following syntax, if you prefer:
import * as package from 'your-package';

console.log(greeter.helloWorld);

dog.ts

import b = require('./baseTypes');

export module Living.Things {
    // Error, can't find name 'Animal', ??
    // Solved: can find, if properly referenced; exporting modules is useless, anyhow
    export class Dog extends b.Living.Things.Animal {
        public woof(): void {
            return;
        }
    }
}

tree.ts

// Error, can't use the same name twice, ??
// Solved: cannot declare let or const variable twice in same scope either: just use a different name
import b = require('./baseTypes');
import d = require('./dog');

module Living.Things {
    // Why do I have to write b.Living.Things.Plant instead of b.Plant??
    class Tree extends b.Living.Things.Plant {
    }
}