Julien Roche - Développeur avancé JavaScript, Web et Java

Il y a quelque temps, j'avais expliqué comment mettre en oeuvre un registre privé pour NPM pour ses projets: http://julienroche.blogspot.fr/2015/11/installer-un-registre-npm-personnel.html Et là je viens de me rendre compte que j'avais omis d'expliquer comment publier son module dans son registre privé ! En effet, le lien ci-dessus ne va expliquer que comment installer Nexus de Sonatype et l'utiliser en somme en tant que mirroring. Maintenant, voyons comment l'utiliser pour publier son module. Tout d'abord, une petite modification dans son package.json. En effet, nous allons devoir indiquer dedans une propriété "publishConfig" afin de dire vers où nous souhaitons publier notre module. Si vous avez été attentif dans la lecture du lien précédent, vous aurez pu constater que nous avons créé un repository dédié à cela, le "npm-internal" Du coup, mettons à jour notre package.json comme suit: { "name" : ...

Il y a quelques mois j'avais fait un article autour de shrinkwrap pour montrer sa grande utilitée:  http://julienroche.blogspot.fr/2016/01/npm-shrinkwrap.html Néanmoins, j'ai pu constater un changement de comportement depuis NPM4 (qui a été détectée ) En effet, avant, si nous faisons la commande suivante: > npm shrinkwrap Sur NPM2, seul les dépendances déclarer dans "dependencies" du package.json étaient pris en compte. Et si nous voulions avoir aussi celle de "devDependencies", il faudrait ajouter l'option "--dev" Sur NPM4, nous avons ... toutes les dépendances ! Aussi bien celle de "dependencies" que de "devDependencies" ! Du coup, il existe cette fois-ci une option NPM pour pallier à ça via " only ". En ligne de commande: > npm shrinkwrap --only=prod Dans le fichier .npmrc: save-exact=true sign-git-tag=false strict-ssl=false only=prod

Il y a désormais quelques mois, j'avais publier un article sur les "awesomes lists":  http://julienroche.blogspot.fr/2015/10/awesome-lists.html Du coup, je fais un nouvel article pour en publier des nouveaux ! Côté NodeJs (encore une fois, merci Sindre Sorhus): NodeJs:  https://github.com/sindresorhus/awesome-nodejs NPM:  Classique:  https://github.com/sindresorhus/awesome-npm "Avancé":  https://github.com/feross/awesome-mad-science Côté JavaScript: JavaScript:  https://github.com/sorrycc/awesome-javascript ES6 tools:  https://github.com/addyosmani/es6-tools Programmation Fonctionnel:  https://github.com/stoeffel/awesome-fp-js Promises:  https://github.com/wbinnssmith/awesome-promises Côté outils / frameworks JavaScripts: Electron:  https://github.com/sindresorhus/awesome-electron React: Le framework:  https://github.com/enaqx/awesome-react Native:  https://github.com/jondot/awesome...

La solution souvent que nous trouvons ou qui nous vient naturellement est d'écrire un service angular afin de fournir l'instance Lodash (ou Underscore): angular .module( ' underscore ' , []) .factory( ' _ ' , function () { return window._; }); Et il existe même un projet pour cela: angular-underscore-module . Le hic de cette approche est que Lodash ne peut être injecté dans des provider. Ce qui est dommage. Du coup, privilégiez la syntaxe suivante: angular .module( ' underscore ' , []) .constant( ' _ ' , window._); Et là, tout va bien dans le meilleur des mondes :)

Il arrive dans nos projets que nous déclarions dans le bower.json ou dans le package.json un lien Git qui permet de récupérer un composant. Jusque-là, rien de gênant. En revanche, il arrive que ces liens pointent vers des repos Git privés. Quand nous développons, nous allons avoir un prompt sur les commandes "bower install" ou "npm install" qui va nous demander d'entrer le login / mot de passe. Donc cela peut se résoudre, même s'il y a de fortes chances que ce prompt apparaisse à chaque fois. Le plus gênant est dans nos CI où fatalement, il n'y a pas d'humain pour interagir avec le prompt. Du coup, la solution naïve est de fournir dans les liens Git un login / mot de passe ... ce qui n'est pas vraiment une bonne idée. Il existe un moyen plutôt simple d'éviter cette solution: utiliser le "netrc". C'est un fichier qui va contenir nos crédentials pour les différents hosts Git. Voici la procédure pour que cela f...

Parfois, j'aimerai que la vie soit comme dans cette illustration de XKCD : Malheureusement, parfois, nous ne sommes pas sudo :'( Du coup, il arrive parfois sur nos environnements de CI ou tout simplement sur nos postes locaux que nous ayons des erreurs du style "run the command as admin". En fouillant un peu la documentation, on s'aperçoit que c'est un besoin inhérent, et NPM et Bower ont prévu le coup. Pour Bower, il existe une option " allow-root " qui permet de lancer une ligne de commande en étant "sudo". Personnellement, il a fallu que je l'utilise sur un CI jenkins où bizarrement, la configuration était telle que nous ne pouvions pas télécharger les dépendances Bower sans être sudo. Du coup au lieu de: > bower install Il suffit de faire > bower install --allow-root Pour NPM, c'est un peu différent. Il existe une option que nous pouvons définir soit dans nos fichiers ...