Edit: Détecter si le colis est en cours d'installation à partir de repo git
Je n'ai pas compris la question correctement.
Ci-dessous sont des choses que j'ai écrit, mais sont un peu hors-sujet.
Pour l'instant, si vous voulez exécuter build.js seulement lors de l'installation de repo:
Fichiers dans repo:
.gitignore
.npmignore
ThisIsNpmPackage
build.js
package.json
L' .gitginore:
ThisIsNpmPackage
L' .npmignore:
!ThisIsNpmPackage
Dans le package.json:
"scripts": {
"install": "( [ ! -f ./ThisIsNpmPackage ] && [ ! -f ./AlreadyInstalled ] && echo \"\" > ./AlreadyInstalled && npm install . && node ./build.js ) || echo \"SKIP: NON GIT SOURCE\""
}
L'idée est de rendre le fichier ThisIsNpmPackage disponible sur le repo, mais pas dans le package npm.
Installer le crochet c'est juste un morceau de bashy script pour vérifier si ThisIsNpmPackage existe. Si oui, alors nous exécutons npm install . (cela permettra de s'assurer que nous avons devDependencies. Fichier AlreadyInstalled est généré pour éviter de boucle infinie
(npm install de manière récursive invoquer installer le crochet)
Lors de la publication, je n' git push et npm publish
Notez que mnp publier peut être automatisée par le biais d'outils CI - githooks
Ce petit hack avec le fichier ThisIsNpmPackage rend la détection de source disponible.
Les résultats de l'invocation d' npm install dumb-package:
"IGNORER: NON-SOURCE DE GIT"
Et l'exécution d' npm install https://github.com/styczynski/dumb-package
Les fichiers seront construits
Les questions
Les principaux problèmes auxquels nous sommes confrontés ici sont les suivantes:
Avez à faire, npm publish ... à chaque fois
Parfois, c'est trop de douleur pour corriger un petit bug, puis poussez vers le repo et oublier de le publier sur npm. Quand je travaillais avec un microservices projet qui a environ 5 autonome sous-projets divisés en modules, le problème que j'ai trouvé un problème, il fixe et oublier de le publier dans chaque endroit que j'ai eu était vraiment ennuyeux.
Ne veux pas pousser lib dans les pensions de titres, parce que c'est dérivée à partir de sources
La relocalisation et la fusion est encore plus ennuyeux.
-
Pas de gâchis, avec .gitgnore
Bon, je sais que le problème lorsque vous avez une source de fichiers que vous devez inclure à l'intérieur de pensions, mais jamais les modifier, ou parfois supprimer? C'est tout simplement malade.
Edit: mnp crochets
Comme @Roy Tinker a mentionné, il existe la possibilité qu'un package pour exécuter une commande lors de l'installation.
Il peut être réalisé via npm crochets.
"install": "npm run build"
Et nous exécutons l':
npm install https://github.com/<user>/<package>
Edit:
OP question des commentaires:
Mais cela va lancer une installation pour tout le monde de télécharger le module de mnp droit? Cela est particulièrement problématique étant donné que les dev dépendances ne seront pas installées pour les personnes téléchargeant le module de mnp. Les libs utilisées pour construire l'application de la tour de babel, etc ne sera pas installé.
Remarque: Mais si vous voulez une version spécifique de l'ensemble (production/dev) avec ou sans dev dépendances vous pouvez l'installer via:
npm install --only=dev
L' --seulement={prod[oupe]|dev[développement]} argument sera la cause soit seulement devDependencies ou seulement non-devDependencies être installé indépendamment de la NODE_ENV.
Une meilleure solution, à mon avis, est d'utiliser:
npm install <git remote url>
Et puis à l'intérieur de paquet.json préciser:
"scripts": {
"prepare": "npm run build"
}
Si le package installé contient préparer un script, de ses dépendances et devDependencies sera installé, et le préparer script sera exécuté, avant que le paquet est emballé et installé.
Exemple:
npm install git+https://isaacs@github.com/npm/npm.git
Lire le mécanisme national de prévention docs là: npm install
Edit: module de proxy (technique avancée)
C'est une sorte de mauvaise pratique, mais bon à savoir.
Parfois (comme dans le cas de l' Électron cadre vous avez besoin d'installer d'autres paquets externes ou des ressources/des modules en fonction de diverses conditions).
Dans ces cas, le proxy idée est utilisée:
- Vous faire un module qui se comporte comme installateur et installe, en fonction des choses que vous voulez
Dans votre cas, préparer script sera suffisant, mais je laisse cette option, car il peut être parfois utile.
L'idée est que vous écrivez un module et d'écrire une installation kook pour elle:
"scripts": {
"install": "<do the install>"
}
Dans ce scénario, vous pouvez placer là:
npm install . && npm run build
Qui installer tous les devDependencies de toute façon (comme cités préparer des cas), mais c'est un peu du piratage informatique.
Si vous souhaitez en faire le vrai piratage il y a:
"scripts": {
"install": "curl -L -J -O \"<some_url>\""
}
qui télécharger manuellement les fichiers à l'aide de -nix commande curl
Il devrait être évité, mais il y a une option dans le cas du module qui a d'énormes fichiers binaires pour chaque plate-forme et que vous ne souhaitez pas installer tous.
Comme dans le cas de l'Électron où vous avez compilé les fichiers binaires (chacun pour la plate-forme séparée)
Si vous voulez que les gens font install package pas install package-linux ou package-window etc.
Afin de vous fournir des personnalisés install script dans l' package.json
{
...
"scripts": {
"install": "node ./install_platform_dep.js"
}
}
Puis lors de l'installation d' module le install_platform_dep.js script sera exécuté. À l'intérieur d' install_platform_dep.js vous placez:
// For Windows...
if(process.platform === 'win32') {
// Trigger Windows module installation
exec('npm install fancy-module-windows', (err, stdout, stderr) => {
// Some error handling...
}
} else if ... // Process other OS'es
Et ce uniquement de façon manuelle installe tout.
Remarque: une Fois de plus, cette approche est utilisable avec la plate-forme en fonction des modules et si vous utilisez que c'est probablement le problème de conception avec votre code.
Construire sur la CI
Ce qui me vient à l'esprit est la solution que j'ai utilisé vraiment pour une longue période (de construction automatique avec CI des services).
La plupart des services CI' objectif principal est de tester/build/publier votre code lorsque l'on pousse à la branche ou à faire d'autres actions avec le repo.
L'idée est que vous fournissez fichier de paramètres (comme travis.yml ou .gitlab-ci.yml) et les outils de prendre soin de tout le reste.
Si vous avez vraiment ne voulez pas inclure la lib dans le projet, seulement de la confiance IC à tout faire:
- Githook va déclencher la construction lors de la validation (sur une branche ou tout autre - c'est juste une question de configs)
- CI permettra de construire vos fichiers, puis les passer à la phase de test et de publier
Maintenant, je travaille sur Gitlab sur mon propre projet de faire (comme une partie de hobby) certains page web. Le Gitlab configuration qui crée le projet ressemble à cela:
image: tetraweb/php
cache:
untracked: true
paths:
- public_html/
- node_modules/
before_script:
- apt-get update
stages:
- build
- test
- deploy
build_product:
stage: build
script:
- npm run test
build_product:
stage: build
script:
- npm run build
deploy_product:
stage: deploy
script:
- npm run deploy
Quand j'ai fusionner dans la branche principale les événements suivants se produisent:
- CI exécute
build stade
- Si la génération réussit alors
test stade est lancé
- Si
test phase est ok, alors enfin la scène deploy est déclenchée
Le script est la liste des commandes unix pour être exécuté.
Vous pouvez spécifier n'importe quel Panneau de l'image dans le fichier de configuration, afin de l'utiliser en fait une version Unix que vous voulez avec certains (ou pas) préinstallé outils.
Il s'agit d'un package de déploiement-git qui déploie des objets pour le désiré des pensions de la branche.
Ou ici (Travis CI) le morceau de config qui publie des objets pour les pensions de titres:
travis-publier-à-git
(Je l'ai utilisé par moi-même)
Alors, bien sûr, vous pouvez indiquer CI s'exécuter:
npm publish .
Parce que CI exécute des commandes Unix, alors il peut (au moins un groupe de CI de fournisseurs de là):
- Publier des balises (balise de version peut-être?)
- Déclencheur de script pour mettre à jour la version du projet dans tous les fichiers readme et partout
- Vous envoyer une notification si toutes les phases réussi
Donc ce que je fais:
Je m'engage, de pousser et de laisser les outils de faire tout ce que je veux.
En attendant, je fais aussi d'autres changements et après un à dix minutes en obtenir la mise à jour du rapport par mail.
Il y a beaucoup de CI fournisseur de:
Ici je joins un autre exemple de mon autre projet (.travis.yml):
language: generic
install:
- npm install
script:
- chmod u+x ./utest.sh
- chmod u+x ./self_test/autodetection_cli/someprogram.sh
- cd self_test && bash ../utest.sh --ttools stime --tno-spinner
Si vous configurez CI de pousser et de publier votre colis, vous pouvez toujours être sûr d'utiliser la dernière pointe de la version de votre code sans se soucier hein, je dois courir aussi cette commande maintenant... problème.
Je vous recommande de choisir l'un de l'IC fournisseurs là-bas.
Les meilleurs d'entre eux vous offrons des centaines de capacités!
Lorsque vous obtenez automatiquement utilisé pour faire publier, de test et de phases de construction, vous verrez comment elle aide à profiter de la vie!
Alors pour commencer un autre projet avec des scripts automatiques il suffit de copier les configs!
Résumé
À mon avis mnp préparer script est une option.
Vous pouvez aussi peut-être envie d'essayer d'autres.
Chacune des méthodes décrites ci-dessus a ses inconvénients et peut être utilisé en fonction de ce que vous voulez atteindre.
Je veux juste offrir des options espère que certains d'entre eux seront s'adapter à votre problème!
