Typescript: Meerdere projecten in oplossing

Question

Typescript: Meerdere projecten in oplossing

stemmen

10

Ik ben klaar met het overzetten van een JavaScript-bibliotheek om typoscript in Visual Studio 2012. Al met al is ongeveer 60 klassen, met elke klasse gedefinieerd in zijn eigen .TS bestand.

Alle lessen worden gedefinieerd in dezelfde module. Ik gebruik verwijzing opmerkingen Reder aan die gedefinieerd zijn in andere bestanden. De lay-out van elk bestand ziet er als volgt uit:

///<reference path='./../myotherclass.ts' />

module MyModule {

    export class MyClass {
        ...
    }

}

Nu heb ik een tweede project in dezelfde oplossing die gaat naar de daadwerkelijke toepassing met behulp van mijn nieuw geport bibliotheek gemaakt. Ik moet mijn bibliotheek een of andere manier op te nemen en ik denk dat dat is wat de module systeem voor. Maar ik weet niet zeker wat file (s) te importeren als MyModule is verspreid over tientallen bestanden. Is dit wat ik het dossier .d.ts kan gebruiken?

Ook, in staat zijn om een module te importeren, moet worden verklaard met de 'export' keyword maar als ik dat doe dan is het niet aangetoond aan de hand opmerkingen meer.

Op de top van dat indien beide projecten worden opgesteld zodat de compiler productie gemakkelijk kan worden gebruikt door een module loader als requireJS.

Wat is de beste aanpak om dit alles te bereiken?

Dank je!

typescript

De vraag is gesteld op 07/10/2012 om 16:41
bron van user vexator

In andere talen...

1 antwoorden

nxn · Accepted Answer · 2012-10-07 20:22

Ok, dus laat ik beginnen met te zeggen dat "Module" verschillende dingen kan betekenen. Zo is er de "module patroon", dat is wat je "MyModule" creëert. Voor zover ik begrijp, Typescript verwijst naar deze als "Interne Modules" in de taal specificatie, en deze verschillen van "External Modules" die je zou worden geladen met iets als RequireJS. Het belangrijkste onderscheid is dat de externe modules verwachten om hun eigen geïsoleerde omgeving met een vooraf gedefinieerde 'export' object dat ze kunnen gebruiken voor hun functionaliteit exporteren hebben.

Neem een kijkje op de uitgang van de module:

var MyModule;
(function (MyModule) {
    var MyClass = (function () {
        function MyClass() { }
        return MyClass;
    })();
    MyModule.MyClass = MyClass;    
})(MyModule || (MyModule = {}));

Je ziet dat het exporteert dingen in "MyModule" die wereldwijd beschikbaar is voor andere script zal worden gemaakt bestanden u laden met, bijvoorbeeld, een html "script" block. Is dat u noemde je 60 van deze, zou je waarschijnlijk ook de compiler voor het uitvoeren van een enkel bestand dat je zou kunnen opnemen in markup, in plaats van het laden van elk bestand een voor een.

Bewegen op, neem een kijkje op wat er gebeurt met de uitgang als je je module verklaring te veranderen van "module MyModule {...}" naar "export module MyModule {...}":

(function (MyModule) {
    var MyClass = (function () {
        function MyClass() { }
        return MyClass;
    })();
    MyModule.MyClass = MyClass;    
})(exports.MyModule || (exports.MyModule = {}));

Zoals u ziet, is de module nog steeds met behulp van de "module patroon", maar het wordt toegewezen aan als lid van de "export", wat betekent dat het is bedoeld om te worden geladen met bijvoorbeeld knooppunt "nodig" -functie.

In dit geval zou u willen daadwerkelijk gebruik maken van uw module met deze code:

import wrapper = module("./MyModule");
var instance = new wrapper.MyModule.MyClass();

Let op de "./MyModule" naam verwijst eigenlijk naar de bestandsnaam (minus de extensie .js) de module wordt gedefinieerd in (dit is de reden waarom VS zei dat het kon niet die modules voor u te vinden). De code moet samenstellen om iets als:

var wrapper = require("./MyModule");
var instance = new wrapper.MyModule.MyClass();

Aan toe te voegen, zelfs niet meer echt nodig hebt u om iets te doen met de "module" keyword om een module te hebben. Je kon gewoon exporteren van een functie:

// foo.ts
export function foo() {
    ...
};

// some other file in the same dir
import wrapper = module("./foo");
var result = wrapper.foo();

Dit werkt omdat de functie 'foo' direct worden toegewezen aan "export", die zal worden alias naar "wrapper" in het andere bestand.

Om verder op deze verwarrende puinhoop van module gerelateerde dingen toe te voegen, moet ik ook vermelden dat AMD modules zijn steeds verschillend, omdat ze asynchroon worden geladen, in tegenstelling tot knooppunt "nodig". Om Typescript output die je nodig hebt om te passeren in een "--module AMD" parameter om de compiler te krijgen.

Hoe dan ook, ik hoop dat ik legde de situatie goed genoeg om het punt dat u zult in staat zijn om erachter te komen wat je precies nodig hebt / wilt. Het type van de modules eindig je met behulp zal echt afhankelijk van hoe je ze zult gebruiken ... dat wil zeggen, knoop, web, of een mix van beide.