Dattiloscritto: Più progetti in soluzione

Question

Dattiloscritto: Più progetti in soluzione

voti

10

Ho finito il porting di una libreria JavaScript per dattiloscritto in Visual Studio 2012. Tutti in tutte le sue circa 60 classi, con ogni classe definita nel suo file .ts proprie.

Tutte le classi sono definiti nello stesso modulo. Io uso i commenti di riferimento per Reder classi definite in altri file. Il layout di ogni file è simile al seguente:

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

module MyModule {

    export class MyClass {
        ...
    }

}

Ora ho creato un secondo progetto nella stessa soluzione che sta per essere l'applicazione reale utilizzando la mia libreria di recente porting. Devo includere la mia libreria in qualche modo e credo che sia ciò che il sistema del modulo è per. Tuttavia, non sono sicuro di quello file (s) per importare come MyModule si sviluppa su decine di file. E 'questo quello che posso utilizzare il file .d.ts per?

Inoltre, per essere in grado di importare un modulo, deve essere dichiarata con la parola chiave 'esportazione', ma se lo faccio poi non si trova più da commenti di riferimento.

In cima a tutto questo, entrambi i progetti devono essere compilati in modo che l'uscita compilatore può essere facilmente utilizzato con un caricatore modulo come requireJS.

Qual è l'approccio migliore per realizzare tutto questo?

Grazie!

typescript

È pubblicato 07/10/2012 alle 16:41
fonte dall'utente vexator

In altre lingue...

1 risposte

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

Ok, quindi mi permetta di cominciare dicendo che "Modulo" può significare cose diverse. Ad esempio, c'è il "modello di modulo", che è ciò che crea la vostra "MyModule". Per quanto ho capito, dattiloscritto si riferisce a questi come "moduli interni" nella specifica lingua, e queste differiscono da "Moduli esterni" che si sarebbe di carico con qualcosa di simile RequireJS. La distinzione principale è che i moduli esterni si aspettano di avere il proprio ambiente isolato con oggetto un predefiniti 'esportazioni' che possono utilizzare per esportare la loro funzionalità.

Date un'occhiata a l'uscita del modulo:

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

Si vede che si sta esportando le cose in "MyModule", che saranno messi a disposizione a livello globale per altro script file che si carica con, ad esempio, un blocco HTML "script". Essendo che lei ha detto di avere 60 di questi, probabilmente si potrebbe anche impostare il compilatore per produrre un unico file che è possibile includere nel markup, invece di caricare ogni file uno per uno.

Passando, dare un'occhiata a ciò che accade per l'uscita se si modifica la dichiarazione del modulo da "modulo MyModule {...}" a "modulo di esportazione MyModule {...}":

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

Come si vede, il modulo è ancora utilizzando il "modello di modulo" ma viene assegnato a come membro del "esporta", a significare che è destinato a essere caricato con, per esempio, il nodo del "richiedono" la funzione.

In questo caso, si vorrebbe utilizzare effettivamente il modulo con questo codice:

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

Si noti il nome "./MyModule" si riferisce in realtà al nome del file (meno l'estensione .js) il modulo è definito in (questo è il motivo per cui VS stava dicendo che non riusciva a trovare i moduli per voi). Il codice dovrebbe compilare a qualcosa di simile:

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

Per aggiungere a questo, non è più nemmeno realmente bisogno di fare qualcosa con la parola chiave "modulo" per avere un modulo. Si potrebbe semplicemente esportare una funzione:

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

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

Questo funziona perché la funzione di 'foo' verrà assegnato direttamente a "esportazioni", che sarà alias di "wrapper" nell'altro file.

Per aggiungere ulteriore su questo pasticcio confuso di cose legate modulo, Vorrei anche ricordare che i moduli di AMD sono diverse ancora perché sono caricati in modo asincrono, a differenza del nodo "richiedono". Per arrivare a dattiloscritto uscita quelli è necessario passare un parametro "--module AMD" per il compilatore.

Comunque, spero che ho spiegato la situazione abbastanza bene fino al punto che sarete in grado di capire che cosa esattamente avete bisogno / voglia. Il tipo di moduli si finisce per utilizzare realmente dipenderà da come userete loro ... cioè, nodo, web, o qualche combinazione di entrambi.