2017-07-24 5 views
0

J'ai un paquet qui est compilé à un UMD de Tapuscrit puis converti en vars globales par Webpack (Nous devons utiliser Tapuscrit donc un modèle UMD plus flexible est pas une option). Je veux que les applications qui consomment le paquet puissent choisir ce dont elles ont besoin. Ceux-ci seront déployés dans un registre local de MNP. À l'heure actuelle, j'ai un package.json qui répertorie toutes les dépendances et scripts de construction requis. Je ne me dérange pas publier deux paquets différents (probablement différents domaines à savoir @my-umd-packages\my-package et @my-globals-packages\mypackage mais je voudrais garder un seul paquet pour toutes les dépendances et les scripts que son tout de même en dehors de la dernière étape.Publier un module NPM dans deux styles de motif

Quelle est la neatest façon de le faire? est-ce qu'un seul paquet publié en deux endroits avec différentes propriétés main?

Merci pour toute aide

+0

Pourquoi auriez-vous une version avec globals et une avec UMD? UMD revient à une variable globale, c'est une partie cruciale d'être ** Universal ** Module Definition. –

+0

@MichaelJungo - pas un UMD tapuscrit. Il y a une discussion sur les problèmes et quelques solutions de contournement ici https://github.com/Microsoft/TypeScript/issues/8436 – moefinley

+0

Ok, j'ai vu la discussion dans [# 2605] (https://github.com/Microsoft/ TypeScript/pull/2605) et il ne devrait pas être appelé UMD, mais ils ont fini par le faire de toute façon. –

Répondre

0

tapuscrit ne pas fallback une variable globale, qui devrait être partie d'un module UMD Il existe des possibilités de publier plusieurs versions de votre paquet. module eparate pour les globals, car la plupart du temps UMD prend cette partie. La bonne nouvelle est que webpack supporte ce type de module et sera capable de le produire en réglant le output.libraryTarget.

output: { 
    filename: 'mylib.js', 
    library: 'MyLibrary', 
    libraryTarget: 'umd' 
} 

De nombreux paquets publier des versions multiples, par exemple, un des modules ES pour fardeleuses module comme webpack ou Rollup, et un autre qui fonctionne dans le nœud (avec require). Un bon exemple de cela est Redux, qui a un simple build step. Il utilise Babel pour transpiler la source et Rollup pour le bundle, mais le principe est le même pour TypeScript et webpack.

Redux publie trois répertoires (voir unpkg - Redux pour la structure complète publiée):

dist/ # UMD bundles 
es/ # ES modules version (same as lib/ but with ES modules) 
lib/ # Transpiled version to work in Node 

Cela signifie que vous pouvez importer redux/dist/redux.js si vous souhaitez utiliser la version UMD, par exemple dans une balise de script, ce qui est très simple grâce à unpkg (j'espère que c'est l'utilisation principale pour les globals).

<script src="https://unpkg.com/redux/dist/redux.js"></script> 

En outre, il définit the module field qui sera utilisé par fardeleuses, qui bénéficient de modules ES (Rollup - pkg.module pour plus de détails), sinon il va utiliser lib/index.js (le champ main). Avec Webpack, vous pouvez configurer les champs que vous souhaitez utiliser avec resolve.mainFields. Vous pouvez envisager de publier une telle structure, car l'importation de l'ensemble n'est pas toujours nécessaire si vous souhaitez en utiliser certaines parties et que les modules ES activent Tree Shaking dans Webpack, ce que le consommateur de votre bibliothèque appréciera car il réduira la taille du paquet.

+0

Il est bon de savoir que 'resolve.mainFields' existe et qu'il existe un support pour plusieurs modèles de module dans un seul paquet. Cependant, sans ce support s'étendant à Typescript I, j'obtiendrai juste une erreur de compilation lorsque j'utiliserai le pattern qui n'est pas dans 'index.ts' ou' index.d.ts' dans un autre fichier Typescript. – moefinley

+0

Rien ne vous empêche de publier également la source TypeScript, tout ce que vous devez faire pour le faire fonctionner, utilise un chargeur TypeScript dans webpack. Mais vous pouvez importer du JavaScript à partir de TypeScript, ce n'est pas un problème. Pour avoir des définitions de type, vous pouvez les publier et vous y référer avec le champ 'typings', beaucoup de paquets le font (même certains qui ne sont pas écrits en TypeScript, par exemple [Redux] (https://github.com/reactjs/redux /blob/887bf072bbd5eb354f2e2bd2fbd3a4deb8ef1e90/package.json#L8)). –

+0

La source de Typescript ne décrirait que les UMD limitées (CommonJS et AMD seulement) et un 'index.d.ts' généré automatiquement refléterait ceci. Je peux créer manuellement un fichier 'd.ts' qui inclut quelque chose comme' export as namespace myModule' qui refléterait ce que Webpack/Rollup a généré. Mais comment le compilateur Typescript sait-il lequel utiliser si tout est dans un paquet? Je pourrais utiliser des instructions d'importation relatives (c.-à-d. 'Import * comme myModule de '../../../ node_modules/my-module/globals/index'' mais cela présente des inconvénients évidents.) – moefinley