Je pense que cela devrait être un problème standard mais je ne trouve aucune réponse ...
J'ai deux projets dactylographiés - LibraryA et WebserverB. Ce sont des projets séparés et chacun a son propre référentiel git. Ce sont aussi des projets privés - je ne veux pas qu'ils soient disponibles en public.
De toute évidence, je souhaite utiliser LibraryA dans WebserverB. Je pense que la bonne façon de le faire serait via npm, car il gère toutes les autres bibliothèques. Heureusement, npm prend en charge les URL git dans les dépendances, je peux donc le diriger directement vers le référentiel de LibraryA.
Cependant, ce référentiel ne contient pas les fichiers Javascript compilés, uniquement les fichiers TypeScript. Comment puis-je faire fonctionner cela? Ou quelle est la bonne approche dans cette situation?
3 Réponses :
Je suppose que vous pourriez ajouter un script install dans le package.json de la bibliothèque qui le compile. Ensuite, il vous suffit de pointer main et < a href = "https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html" rel = "nofollow noreferrer"> types aux fichiers de sortie.
Hmm ... c'est un moyen, mais cela fait ensuite sortir TypeScript des dépendances de développement et des dépendances complètes
Certes, il pourrait y avoir d'autres solutions.
Si vous ne souhaitez pas installer votre dépendance à partir des sources dans un dépôt git, voici d'autres solutions:
Une solution légère consiste à installer LibraryA via un git clone et à le construire. Ensuite, dans WebserverB / , vous pouvez faire une npm install ../path/to/local/LibraryA :
- npm install
: Installez le package dans le répertoire en tant que lien symbolique dans le projet en cours. Ses dépendances seront installées avant son association. Si
se trouve à l'intérieur de la racine de votre projet, ses dépendances peuvent être hissées au niveau supérieur node_modules comme elles le feraient pour d'autres types de dépendances. ( Source: documentation NPM )
Vous pouvez installer un registre proxy npm privé sur votre serveur, comme Verdaccio . Ensuite, vous pourrez publier votre package avec tous les fichiers compilés.
Vous pouvez publier un vrai package (également avec les fichiers compilés) dans un dépôt privé à partir d'un compte payant.
La documentation NPM indique une autre option:
- npm install
Récupérez l'url de l'archive tar, puis installez-la. Afin de faire la distinction entre cette option et d'autres, l'argument doit commencer par «http: //» ou «https: //»
Ensuite, publiez un package consistant à le construire, le compresser et le télécharger en tant que nouvelle version dans votre référentiel Github privé. Après cela, il devrait être possible d'accéder à l'archive tar via une URL en utilisant un jeton d'accès personnel?
Attends attends. Je souhaite installer ma dépendance depuis un référentiel git. Je n'arrive tout simplement pas à comprendre comment le faire correctement.
@ Vilx- Je viens d'avoir une idée. J'ai modifié ma réponse pour l'ajouter comme solution 4.
Je ne pense pas que vous puissiez pointer npm vers une seule archive tar dans un référentiel GIT. Cela ne dit pas directement mais c'est un peu implicite de la documentation d'installation . Vous pouvez cependant utiliser une URL simple vers l'archive tar. Ou, si vous invoquez déjà un référentiel GIT séparé, pourquoi ne pas créer un référentiel contenant uniquement le package construit? Pas besoin de rien archiver. Cependant, cela devient déjà bizarre, donc une approche plus simple consiste simplement à valider les fichiers JS construits dans votre référentiel source d'origine et à l'utiliser.
Cela a pour effet secondaire de distribuer le code source avec le résultat JS compilé, mais nous parlons de toute façon de packages privés, donc cela ne devrait pas être un problème. Mieux encore, cela pourrait aider au débogage.
@ Vilx- Ou peut-être une archive tar téléchargée dans une version de votre dépôt Github? (J'ai édité la solution 4)
Eh bien, si vous utilisez GitHub, bien sûr. Mais je parlais de paquets privés que vous ne voulez pas montrer au monde. Je suppose que Github a également des référentiels privés. Je me demande si vous pouvez créer une URL vers eux qui contient un nom d'utilisateur / mot de passe intégré?
@ Vilx- Peut-être avec un jeton d'accès personnel . Voici un exemple d'URL utilisant un jeton mais je n'ai pas testé cela.
OK, je vais répondre à ma propre question avec un résumé des autres réponses et quelques options supplémentaires.
Après réflexion, je suis arrivé à une réalisation. La question est - qui et quand exécute tsc pour compiler le Typescript de LibraryA en Javascript? Pour l'essentiel, il n'y a que quelques choix:
Examinons chacun en détail.
La question est alors: où est stocké le résultat publié? Il doit être quelque part où NPM peut y accéder. En tant que tel, il n'y a encore que quelques choix:
Malgré les inconvénients, ce sont toutes des options utilisables.
Le principal inconvénient ici est que cela met immédiatement une dépendance sur le typographie sur WebserverB. Et pas seulement une dépendance de développement, mais une dépendance d'exécution complète. C'est peut-être OK, mais ça devient vraiment bizarre. Comment prévoyez-vous de déployer WebserverB? Cela va-t-il aussi exécuter la compilation? Je ne pense pas que ce soit la voie à suivre. Mais c'est possible. Voir la réponse de H.B. pour plus de détails.
Eh bien, si vous prévoyez de l'utiliser uniquement dans des projets dactylographiés, cela pourrait être OK. Je ne suis pas sûr de l'installer cependant. Vous devrez modifier votre fichier tsconfig.json pour inclure node_modules / LibraryA dans la compilation. C'est bizarre. Et votre IDE en sera-t-il heureux? Dans l'ensemble, cela ne semble pas non plus une bonne idée. C'est comme se battre / abuser du système et cela se termine rarement bien.
En fin de compte, je pense que j'irai avec l'approche "commit compiled JS". Parce que " tout simplement faux " n'est pas un bon argument. Et comme il s'agit d'un projet privé, les sources supplémentaires publiées ne sont pas non plus un problème. En fait, ils aideront peut-être même à déboguer.