Scrittura di moduli NPM in Typescript

Question

Sto lavorando al mio primo modulo NPM. Ho lavorato brevemente con dattiloscritto e un grosso problema era che per molti moduli non erano disponibili file di definizione. Quindi ho pensato che sarebbe una buona idea scrivere il mio modulo in dattiloscritto.

Tuttavia, non riesco a trovare alcuna informazione sul modo migliore per farlo. Ho trovato questa domanda correlata "Can I write npm package in coffeescript?" dove le persone suggeriscono di pubblicare solo i file javascript. Ma a differenza dei file coffeescript, i file typescript potrebbero essere utili se vengono utilizzati all'interno di un'applicazione dattiloscritto.

Devo includere i file Typescript durante la pubblicazione di un modulo NPM o devo solo pubblicare i file javascript e fornire i file .d.ts generati su DefinitelyTyped?

Answer 1

Qui è un modulo di esempio Nodo scritto a macchina: https://github.com/basarat/ts-npm-module

Ecco un progetto di esempio dattiloscritto che utilizza questo modulo di esempio https://github.com/basarat/ts-npm-module-consume

Fondamentalmente è necessario:

• compilare con commonjs e declaration:true
• generare un file .d.ts

E poi

• avere il vostro IDE leggere il generato .d.ts.

Atom-dattiloscritto solo fornisce un bel flusso di lavoro intorno a questo: https://github.com/TypeStrong/atom-typescript#packagejson-support

Answer 2

È possibile utilizzare autodts per gestire la distribuzione e l'utilizzo di .d.ts file da NPM anche senza il supporto dall'atomo IDE.

autodts generate sarà impacchettare tutto tuo .d.ts file insieme per la pubblicazione sul NPM, e autodts link gestisce riferimenti ad altri pacchetti installati, che non possono essere sempre direttamente sotto node_modules in un progetto più ampio suddivisi in più sottopacchetti.

Entrambi i comandi leggono le loro impostazioni da package.json e tsconfig.json nello stile "convenzione sulla configurazione".

C'è another answer su stackoverflow e un blog post con ulteriori dettagli.

Answer 3

Questa è una risposta più recente che utilizza TypeScript 1.8.10:

La mia struttura del progetto è:

| 
|--- src 
|--- test 
|--- dist  <= My gulp file compiles and places the js, sourcemaps and .d.ts files here 
|  |--- src 
|  |--- test 
|--- typings 
.gitignore 
.npmignore 
gulpfile.js 
package.json 
README.md 
tsconfig.json 
tslint.json 
typings.json 

ho aggiunto quanto segue in .npmignore per evitare di includere i file estranei e mantenere il minimo indispensabile per avere il pacchetto importato e di lavoro:

node_modules/ 
*.log 
*.tgz 

src/ 
test/ 
gulpfile.js 
tsconfig.json 
tslint.json 
typings.json 
typings 
dist/test 

mio .gitignore ha:

typings 

# ignore .js.map files 
*.js.map 
*.js 
dist 

Il mio package.json ha:

"main": "dist/src/index.js", 
"typings": "dist/src/index.d.ts", 

Ora scappo: npm pack

Il file risultante (quando decompresso) ha la seguente struttura:

| 
|--- dist 
|  |--- src 
|    | 
|    index.js 
|    index.js.map 
|    index.d.ts 
| 
package.json 
README.md 

Ora vado al progetto in cui voglio usare questo come una libreria e tipo: npm install ./project-1.0.0.tgz

Si installa correttamente.

Ora crea un file index.ts nel mio progetto in cui ho appena installato il NPM import Project = require("project");

Digitando Project. mi dà le opzioni Intellisense che era il punto di tutta questa esercitazione.

Spero che questo aiuti qualcun altro a utilizzare i propri progetti npm TypeScript come librerie interne nei loro progetti più grandi.

PS: Credo che questo approccio di compilazione progetti NPM moduli che possono essere utilizzati in altri progetti ricorda il .dll nel mondo .NET. Potrei benissimo immaginare i progetti organizzati in una soluzione in VS Code in cui ogni progetto produce un pacchetto npm che può quindi essere utilizzato in un altro progetto nella soluzione come dipendenza.

Poiché ho impiegato un bel po 'di tempo per capirlo, l'ho postato nel caso qualcuno fosse bloccato qui.

ho anche postato per un bug chiuso a: https://github.com/npm/npm/issues/11546

---

Questo esempio è stato caricato su Github: vchatterji/tsc-seed

Answer 4

Si dovrebbe pubblicare i sorgenti dattiloscritto originale invece della definizione del tipo. In package.json lasciare che la proprietà 'types' punti al file * .ts.

*.d.ts sono buoni per annotare le librerie JS esistenti, ma come consumatore preferisco leggere il codice del dattiloscritto che passare da definizioni di tipo a codice JS generato in modo discendente.

Answer 5

seguo principalmente il suggerimento Varun Chatterji

Ma, vorrei mostrare un esempio completo di unit testing e la copertura del codice e la pubblicazione in npm e importandoli utilizzando javascript o typescript

Questo modulo è scritto usando typescript 2.2 ed è importante per configurare il gancio prepublish per compilare il codice utilizzando tsc prima di pubblicarlo NPM

https://github.com/sweetim/haversine-position

https://www.npmjs.com/package/haversine-position

Answer 6

A Lossless abbiamo creato uno strumento dattiloscritto dev una fermata per i pacchetti NPM: https://gitzone.gitlab.io/npmts/

Answer 7

modo consigliato nel 2017 con 2.x tipografico:

• creare il progetto come lo faresti normalmente (con test e tutto)
• Aggiungi declaration: true a tsconfig.json a generare tipizzazioni
• Esportare l'API tramite index.ts
• Nel numero package.json, puntare ai tipi digitati. Ad esempio se il tuo outDir è dist, quindi aggiungi "types": "dist/index.d.ts" al pacchetto json.
• Creare un .npmignore per ignorare i file non necessari (ad esempio la fonte).
• Pubblicare in npm con npm publish. Utilizzare le specifiche semver per gli aggiornamenti (patch/bug fix npm version patch, additivi non rottura npm version minor, rompendo api cambia npm version major)

Dal momento che mi ha fatto un po 'per vagliare tutte le risorse non aggiornati su questo argomento su internet (come quello in questa pagina ...) Ho deciso di concludere l'operazione in how-to-write-a-typescript-library con un esempio aggiornato minimo.