Riferimenti cross-progetto tra due progetti

È ansible creare un riferimento tra due progetti TypeScript? Supponiamo di avere la seguente struttura di progetto:

Struttura

Module1.ts contiene:

 module TestModule { export interface Interface1 { } } 

Module2.ts contiene:

 module TestModule { export interface Interface2 extends Interface1 { } } 

Test1 è referenziato in Test2 . Ho ricevuto un errore Could not find symbol 'Interface1' in Module2.ts . Funziona all’interno di un progetto, ma non so come renderlo visibile dall’altro progetto … Forse non è ansible per ora.

    [Modifica 1.]
    Quando provo a utilizzare il modello TestModule.Interface1 , ottengo lo stesso errore (detto in modo diverso). Ma IntelliSense vede la mia Interface1 :

    IntelliSense

    [Modifica 2.]
    Ho notato che non posso usare i file dell’altro progetto. Anche se ho un riferimento corretto ( /// <reference ... ) aggiunto e collegato tutti i file nel mio primo progetto.

    Ci sono molti modi in cui puoi farlo.

    Opzione 1 – Riferimenti al progetto (TypeScript 3.0+)

    Se si utilizza TypeScript 3.0, esaminare i riferimenti del progetto. Leggi di più qui .

    Opzione 2 – Crea script

    Usa qualcosa come gulp-typescript , grunt-ts , o solo uno script batch per copiare i file in una cartella nel progetto principale.

    In alternativa, eseguire un evento di build in Visual Studio che copierà i file sul progetto principale.

    Opzione 3 – pacchetto npm

    Se si utilizza npm, è ansible creare un pacchetto per l’altro progetto. Quindi puoi usare il tuo pacchetto nel tuo progetto principale. Specificare una dipendenza locale è un buon modo per farlo o usando qualcosa come sinopia , che è un server di repository privato. Non l’ho mai usato, ma sembra che funzionerebbe bene.

    Opzione 4: pacchetto NuGet

    Potresti esaminare la creazione di un pacchetto nuget e quindi installarlo localmente .

    Opzione 5 – --declaration --outDir opzione del compilatore

    È ansible impostare l’opzione del compilatore --outDir o la proprietà outDir in tsconfig.json con la directory sull’altro progetto, quindi anche compilarlo con --declaration modo che generi anche i file di dichiarazione ( .d.ts ). Ad esempio: --declaration --outDir ../Test1/External .

    Risposta originale (utilizzando --out )

    Puoi fare qualcosa di simile in Visual Studio se fai clic destro sul progetto della tua libreria e fai clic su Proprietà. Nella scheda TypeScript Build , deseleziona l’opzione Combine JavaScript output into file e specifica la posizione nel progetto principale che vuoi che vada (Es. $(SolutionDir)/TypedApp/External/TypedLibrary.js ). Quindi selezionare anche Generate declaration files per generare un file .d.ts .

    Impostazione del progetto per build automatizzati

    Una volta fatto, crea il tuo progetto di libreria e poi includi .js e .d.ts nel tuo progetto principale. Includi il file .js nel tuo html e .d.ts riferimento a .d.ts nei tuoi file typescript.

    Includi file nel progetto principale

    Ogni volta che ricostruisci il progetto della libreria, esso aggiornerà automaticamente il progetto principale con le modifiche.

    La soluzione suggerita da @dhsto funziona ma ho trovato un’alternativa usando le cartelle collegate. Ne ho scritto in dettaglio in questo articolo , ecco come può essere implementato:

    Può essere realizzato creando una cartella per contenere i tuoi riferimenti, mi piace nominare questo “_referencesTS”, la cartella conterrà tutti i link ai file da Test1. Questo può essere fatto individualmente, ma diventerebbe molto complicato se dovesse essere fatto per ogni nuovo file TS. Il collegamento di una cartella tuttavia collegherà tutti i file sottostanti, ciò può essere fatto modificando il file csproj.

    Per modificare il file, fare clic con il pulsante destro del mouse sul progetto Test2 e fare clic su ” Unload Project “, quindi fare clic con il pulsante destro del mouse sul progetto e fare clic su ” Edit Test2.csproj “. Passare al che contiene i tag e inserire il seguente codice:

      _referencesTS\%(RecursiveDir)%(FileName)  

    Sostituisci il percorso relativo alla posizione dei tuoi file TS in Test1, questo usa il carattere jolly (*) per colbind tutti i file .ts (dettati da *.ts ) all’interno di tutte le sottocartelle (dettato da \**\ ) ..

    I file TS all’interno di queste cartelle appariranno ora collegati all’interno di Test2, consentendo il riferimento automatico al typescript.

    Nota: l’unico svantaggio di questo approccio è che quando un nuovo file viene aggiunto a Test1 in una cartella collegata, l’utente deve scaricare e caricare il progetto o chiudere e aprire la soluzione affinché appaia in Test2.

    Frustrato dallo stato delle cose, ho scritto un pacchetto NuGet che risolve principalmente questo problema. Usando il pacchetto NuGet puoi semplicemente aggiungere un riferimento da un progetto a un altro e farà il lavoro di copiare i file in un modo che sia sicuro dal modificare accidentalmente il file sbagliato e dare comunque intellisense e debug.

    I dettagli possono essere trovati in Readme.md, oppure puoi semplicemente installare il pacchetto NuGet ed eseguire (consiglio di leggere almeno la sezione come usare).

    https://github.com/Zoltu/BuildTools.TypeScript.FromReferences

    Voglio solo aggiungere alla risposta di David Sherret che i file lib del progetto TypedApp potrebbero essere aggiunti come file di link invece che in base agli eventi di post-build. Sto riscontrando alcuni problemi con gli eventi di post-build in grandi soluzioni con molti progetti e i file di link ora funzionano bene per me. (Non posso aggiungere un commento alla risposta perché ho solo 35 punti reputazione).

    Se si sta compilando il parametro --out , è sufficiente fare riferimento a Module1.ts di Module2.ts utilizzando /// Per ulteriori informazioni sui modelli di organizzazione del codice in TypeScript, consultare http://www.youtube.com/watch?v = KDrWLMUY0R0 & hd = 1

    Ciò che i servizi linguistici di Visual Studio vedono disponibili (che è tutto) è diverso da ciò che si è compilato ed effettivamente disponibile in fase di runtime.

    Se è necessario condividere il codice tra più progetti, è sempre ansible creare un collegamento simbolico su ciascun progetto in cui è necessario. http://en.wikipedia.org/wiki/Symbolic_link

    La risposta di basarat è la soluzione più affidabile per i riferimenti TypeScript cross-project. Tuttavia, quando si uniscono codice TypeScript condiviso con un TypeScript del progetto di riferimento (importante, ad esempio, se è necessario selezionare versioni ECMAScript diverse), il file Mappa sorgente non viene risolto nelle directory del progetto condiviso, pertanto il debug non funzionerà (in Infatti, Visual Studio si blocca spesso dopo l’aggiunta di punti di interruzione ai file a cui fa riferimento un altro progetto).

    File collegati di qualsiasi tipo (collegamenti di Visual Studio e collegamenti simbolici) non funzionano con il debug in qualsiasi sistema (Visual Studio, Chrome, WebStorm, ecc.) – i file collegati essenzialmente non esistono per il debugger ASP.NET, né qualsiasi altro debugger; esistono solo in Visual Studio.

    Si prega di vedere questa domanda / risposta che indica che cosa ha funzionato bene sia per la manutenzione del codice solido sia per il debug in Visual Studio, Chrome e Firefox, pur mantenendo la capacità di combinare il codice condiviso con il codice dei progetti di riferimento (importante, ad esempio, se si è necessario scegliere come target diverse versioni di ECMAScript): Visual Studio: come eseguire il debug di TypeScript in un progetto condiviso utilizzando IIS Express e riferimenti a più progetti (nessun collegamento o duplicazione di file)

    La risposta accettata non consente il debug in Visual Studio quando viene impostato un punto di interruzione nel progetto condiviso . (Nel migliore dei casi il debugger si fermerà su una riga nel javascript compilato, ma non il Typescript originale e certamente non nella sua posizione originale del progetto.)

    Nelle proprietà del progetto condiviso, supponiamo che l’ output Combina Javascript in [un singolo file] sia selezionato e impostato su AllShared.js , che rende anche un file AllShared.d.ts perché Genera file di dichiarazione è selezionato e crea anche un AllShared.js.map perché Genera mappe di origine è selezionato.

    Il progetto di referenziazione NON deve copiare o colbind questi file nel modo in cui funziona la soluzione accettata. Anziché:

    Parte 1, nel progetto di riferimento, crea /typings/tsd.d.ts se non esiste già e aggiungi alla fine di quel file la riga /// . Una volta fatto ciò, (e almeno una compilazione di successo di SharedProject è fatta), Intellisense e il compilatore Typescript dovrebbero vedere Interface1 ecc. (Probabilmente otterrete una linea rossa ondulata che sottolinea l’istruzione se il percorso / file non esiste , che è bello.)

    Parte 2, nel index.html del progetto di riferimento, aggiungi la riga prima dei tag script di quel progetto. La parte localhost proviene dalle proprietà del progetto condiviso, dalla scheda Web, dall’URL del progetto. (Funzionano sia “IIS Express” che “IIS locale”).

    Ora quando esegui il progetto di riferimento, dovresti vedere Internet Explorer ** richiedere i file pertinenti dai rispettivi “siti web”. I punti di interruzione di Visual Studio devono essere colpiti indipendentemente dal fatto che siano in SharedProject o nel progetto di riferimento.


    . Sebbene questa soluzione funzioni senza gulp / grunt / powershell, l’ output Combine Javascript di Visual Studio in un unico file non unisce i file in un ordine particolare e alla fine interromperà il codice. Quindi dovrai aggiungere Gulp / etc. al progetto di riferimento per inserire un '; } })) .pipe(gulp.dest('./')); });