Forem: Benjamin Auzanneau

Le package.json

Benjamin Auzanneau — Fri, 30 Jan 2026 00:12:39 +0000

Le manifeste

Le package.json est le fichier manifeste d'un projet JavaScript. Il raconte ce que ton projet est, ce dont il dépend et comment il se construit ou se lance.

L'origine

Au debut de Node.js, chaque module devait declarer son nom, sa version et ses dépendances pour etre installé correctement. Le package.json s'est imposé avec npm comme format standard pour decrire un package.

C'etait un moyen simple et lisible de partager un module et de permettre a npm de résoudre les dépendances.

Il n'y a pas que npm qui utilise le package.json : yarn, pnpm et d'autres gestionnaires de paquets s'appuient aussi dessus avec une façon différente de gérer les dépendances et surtout, le moyen de les résoudre.

Les attributs

Dans les grandes lignes, on trouve plusieurs categories de champs dans le package.json :

Catégorie	Description
Identité	`name`, `version`, `description`, `license`, `author`
Dépendances	`dependencies`, `devDependencies`, `peerDependencies`, `optionalDependencies`
Scripts	commandes standardisées (`npm run dev`, `build`, `test`, etc.) ou non
Compatibilité	`engines`, `os`, `cpu` pour cadrer l'environnement
Publication	ce qui est inclus dans le package, la version, les fichiers d'entrée
Customisation	des champs spécifiques aux outils (babel, eslint, jest, etc.) ou tout simplement que vous souhaitez utiliser

Dans la partie scripts, j'ai récemmenet découvert un mécanisme sympa : pre<nomScript> et post<nomScript> se lancent automatiquement avant/après n'importe quel script (ex: prebuild / postbuild autour de build).

{
  "name": "mon-projet", // identite du package
  "version": "1.0.0", // version publiee
  "description": "Mon app de demo",
  "license": "MIT", // license du package
  "author": "necraidan",
  "scripts": {
    "dev": "vite", // commande de dev
    "build": "vite build", // build de production
    "test": "vitest" // tests
  },
  "dependencies": {
    "react": "^18.3.0" // deps runtime
  },
  "devDependencies": {
    "vite": "^5.4.0", // outils de dev
    "vitest": "^2.1.0"
  },
  "peerDependencies": {
    "react": ">=18" // compatibilité attendue
  },
  "optionalDependencies": {
    "fsevents": "^2.3.3" // optionnel (ex: macOS)
  },
  "engines": {
    "node": ">=20" // version node ciblee
  },
  "eslintConfig": {
    "extends": ["eslint:recommended"] // champs custom
  }
}

Les types de dépendances

Type	Description
`dependencies`	indispensables au fonctionnement de l'app en production
`devDependencies`	utiles en développement (tests, lint, build), pas nécessaires en prod
`peerDependencies`	indiquent la compatibilité attendue avec un autre package sans l'embarquer soi‑même (ex. une lib React qui attend React installé)
`optionalDependencies`	optionnelles ; si l'installation échoue, npm continue quand même. À toi de gérer l'absence au runtime
`bundleDependencies`	dépendances embarquées lors de la publication du package

Pour aller plus loin, la documentation officielle du package.json.

Focus sur les `peerDependencies`

Une peerDependency, c'est une dépendance que ton package n'installe pas lui-même : il déclare seulement une compatibilité.

le but : éviter les doublons et les conflits de versions (cas typiques : eslint, vite, react côté librairies).

Depuis npm 7+, les peers sont prises en compte automatiquement pendant la résolution et des conflits de versions peuvent faire échouer l'installation :

{
  "name": "eslint-plugin-acme",
  "peerDependencies": {
    "eslint": "^9.0.0"
  },
  "peerDependenciesMeta": {
    "typescript": {
      "optional": true
    }
  }
}

Ici, le plugin n'installe pas eslint : il annonce juste la version attendue. C'est le projet hôte qui doit fournir eslint (en dependencies ou devDependencies selon son usage).

Le bloc peerDependenciesMeta indique que typescript est une peer optionnelle : si typescript n'est pas présent dans le projet hôte, l'installation ne doit pas échouer pour cette raison.

Le lockfile de npm : le package-lock.json

Un lockfile permet de fixer des dépendances. Il est conçu pour être versionné dans votre repo afin de pouvoir avoir une rejouabilité des installations prédictibles. Cependant, cela peut varier selon l’OS ou l'architecture, les dépendances optionnelles ou les champs encore les ce qui est spécifié dans les champs os/cpu.

Le package-lock.json décrit l’état exact résolu : l’arbre complet des dépendances (y compris transitives), avec versions précises, sources de téléchargement (resolved) et empreintes (integrity).

Ce qu’on trouve dedans

Concrètement, on va y trouver un lockfileVersion pour la version du format. La partie packages est la description des packages par chemin, avec resolved et integrity (présent avec le package-lock.json v2+, npm 7+ ; aujourd'hui, npm 9+ génère un lockfileVersion: 3).

`npm install` vs `npm ci`

La commande npm install va installer les dépendances en s’appuyant sur package.json et le package-lock.json. Il peut le régénérer ou le modifier selon les cas.

La commande npm ci va suivre le package-lock.json, elle échoue si le package.json et le package-lock.json ne correspondent pas, supprime les node_modules (en théorie 😅) avant de lancer l'installation et ne touche pas au package-lock.json.

Cas avancés

npm-shrinkwrap.json a priorité sur package-lock.json et fige l'arbre des dépendances pour un package publié. En pratique, c'est surtout adapté aux applications/CLI publiées, et généralement déconseillé pour les bibliothèques.

L'attribut overrides peut être utiliser pour de forcer une version d’une dépendance transitive pour surcharger une version particulière.

Conclusion

Le package.json décrit l’intention de ton projet (scripts, compatibilité, plages de versions). Le package-lock.json, lui, fige l’état exact installé : c’est ce qui rend les builds reproductibles. En pratique : on versionne le lockfile, on installe avec npm ci en CI, et on relit ses diffs comme du code. C’est ce duo qui évite les “ça marche chez moi” et stabilise le projet dans le temps.

Encore une fois c'est un mémo sans doute trivial en partie mais qui permet de réunir en un seul endroit l'essentiel de ce qu'est le package.json.

Sources

Guide du SemVer avec npm

Benjamin Auzanneau — Wed, 28 Jan 2026 02:21:44 +0000

Je ne compte pas le nombre de fois où je me suis posé la question de ce que faisait les symboles devant les versions dans un package.json sans en être totalement sûrs. On va essayer d'y voir plus clair dans cet article.

Initialement, j'avais rédigé cet article en juillet 2021.

Il comportait une petite erreur sur l'utilisation du caret. J'en ai donc profité pour le corriger et l'enrichir, et j'ai désormais un article dédié au package-lock.json dans la même série.

Le `SemVer`, c’est quoi ?

Le SemVer (Semantic Versioning) est une convention de versionnement qui donne du sens aux numéros de version.

Si l'on s'appuie sur le site officiel, on retrouve la forme :

MAJEURE.MINEURE.CORRECTIF

Pour aller plus loin, n’hésitez pas à consulter semver.org et j'ai un article dédié sur le sujet : SemVer : les bases.

npm va venir enrichir ces notions avec des symboles. Ce sont des ranges (plage de versions en bon français). Elles indiquent ce que le projet accepte comme mises à jour, notamment lors des npm install.

Le symbole `^` : “jusqu’à la prochaine release majeure”

Le caret autorise les mises à jour tant que le premier chiffre non nul reste identique :

"react": "^1.2.3", // >=1.2.3 <2.0.0
"shiki": "^0.2.3", // >=0.2.3 <0.3.0
"tslib": "^0.0.3", // >=0.0.3 <0.0.4

Sur les versions 0.x, le caret est plus restrictif. Dans notre exemple, ^0.2.3 bloque le passage à tout ce qui est supérieur ou égal à 0.3.0.

Le symbole `~` : “patchs uniquement”

Le tilde autorise des changements au niveau correctif, tant que la mineure ne bouge pas :

"shiki": "~1.2.3", // >=1.2.3 <1.3.0
"tslib": "~0.2.3", // >=0.2.3 <0.3.0

Les symboles `>`, `>=`, `<`, `<=`, `=` : comparateurs

Ces opérateurs fonctionnent comme des comparateurs classiques :

"react": ">1.2.3",  // strictement supérieur
"shiki": ">=1.2.3", // supérieur ou égal
"tslib": "<2.0.0",  // strictement inférieur
"axios": "<=2.0.0", // inférieur ou égal
"redux": "1.2.3",   // (ou `=1.2.3`) version exacte

Le symbole `-` : inclusif

Un intervalle avec tiret est inclusif sur les bornes :

"tslib": "1.2.3 - 2.3.4", // >=1.2.3 <=2.3.4
"shiki": "0.2.0 - 0.4.2", // accepte 0.4.2 mais pas 0.4.3

Le symbole `||` : combiner des ensembles

Un intervalle avec le double pipe combine les deux ensembles :

"tslib": "^0.2.0 || >=0.5.0 <1.2.0" // Compatible avec l'ensemble ^0.2.0 ou >=0.5.0 <1.2.0

Le dist-tag : `latest`

Point important : latest n’est pas une règle SemVer. C’est un dist-tag npm.

Exemple :

"shiki": "latest"

Par défaut, la commande npm install <pkg> installe la version pointée par le tag latest (si on ne met ni @<version> ni @<tag>). Un mainteneur peut alors faire pointer latest vers une version qui n’est pas forcément “la plus récente” au sens strict et utiliser d’autres tags (beta, next, etc.).

Bonus : `x`, `*` et les pré-releases `-alpha`, `-beta`

Exemples :

"tslib": "1.2.x", // >=1.2.0 <1.3.0
"shiki": "1.2.*", // >=1.2.0 <1.3.0
"redux": ">=1.2.3-0 <1.3.0" // inclut les pré-releases >=1.2.3-*

Les pré-releases (-alpha, -beta) ont des règles spécifiques : par défaut, elles sont exclues des ranges. Pour les inclure, on peut utiliser une borne avec -0 (ou une version pré-release) dans la range.

Conclusion

La première fois que j'ai rédigé cet article, j'avais essayé d'être le plus minimal possible. Je me suis rendu compte que c'était quand même plus sympa d'aller un peu plus loin, pour bien comprendre le fonctionnement du versionnement avec npm.

J'ai rédigé cet article pour m'en faire un mémo, l'avoir toujours sous la main et le mettre dans mes favoris. Vous pouvez en faire autant !

Sources

Tableau officiel npm sur le SemVer et les ranges : https://docs.npmjs.com/about-semantic-versioning
Calculateur de ranges npm : https://semver.npmjs.com/

Le SemVer

Benjamin Auzanneau — Wed, 28 Jan 2026 02:08:55 +0000

Le Semantic Versioning, plus connu sous le nom de SemVer, est une convention assez simple : avoir des numéros qui indiquent ce qui change.

L’idée n’est pas d’être parfait, mais d’être prévisible pour celles et ceux qui consomment une lib ou un package.

Aux origines

Le Semantic Versioning est formalisé autour de 2010 par Tom Preston-Werner, cofondateur de GitHub.

Le problème est simple : les numéros de version sont utilisés de manière incohérente, chacun fait un peu ce qu'il veut et il est difficile de savoir si une mise à jour va casser une application. L’objectif de cette convention va donc être de donner du sens aux numéros de version, afin qu’ils deviennent exploitables.

Type	Description
MAJEURE	Changements incompatibles avec les versions précédentes
MINEURE	Nouvelles fonctionnalités rétrocompatibles
CORRECTIF	Corrections de bugs rétrocompatibles

Cette simplicité est l’une des raisons majeures de son adoption.

Une convention

Un point fondamental : ce système n’est pas un standard technique et n’est imposé par aucune autorité. La spécification officielle parle explicitement de règles, de recommandations et de bonnes pratiques. Cette convention repose entièrement sur la discipline et la bonne foi des mainteneurs.

Le cœur de la convention : la notion d’API publique

Elle suppose l’existence d’une API publique clairement définie.

Une API est un outil informatique qui permet à un site internet ou à un logiciel de communiquer avec un autre ordinateur et échanger des données.

Source incroyable : https://api.gouv.fr/apropos

C’est cette API qui sert de référence pour décider si un changement est majeur, mineur ou un correctif. En pratique, modifier un comportement interne non documenté n’est pas considéré comme un breaking change au regard de l’API publique, même si cela casse le code de certains utilisateurs. Elle ne protège donc pas les usages implicites, détournés ou non documentés.

C’est un engagement moral, pas une garantie contractuelle.

Le cas particulier des versions `0.x`

La spécification est très claire sur ce point : avant la version 1.0.0, l’API est considérée comme instable. On reviendra sur ce point dans l'article : Guide du SemVer avec npm.

Conclusion

Le SemVer est née d’un besoin très concret : rendre les mises à jour plus prévisibles dans un monde de dépendances automatisées. Il apporte un langage commun, une structure simple et surtout une convention. Mais attention, ça ne fonctionne que si l'ensemble de la chaîne la respecte.

Cette convention aide à faire confiance mais ne dispense pas de vérifier.

Sources

Spécification officielle du Semantic Versioning,

https://semver.org/
Documentation npm – Semantic Versioning, & ranges

https://docs.npmjs.com/about-semantic-versioning
Tom Preston-Werner – Semantic Versioning,

https://tom.preston-werner.com/2010/08/23/semantic-versioning.html
Hynek Schlawack – Semantic Versioning, Will Not Save You

https://hynek.me/articles/semver-will-not-save-you/
Discussions communautaires sur les limites du SemVer

https://clojureverse.org/t/stop-using-semantic-versioning-any-writings-on-this/9951

Npx, c'est quoi ?

Benjamin Auzanneau — Sun, 29 Jan 2023 15:30:32 +0000

Npx est un outil développé par npm qui facilite l'exécution de packages Node.js.

Il est livré avec npm à partir de la version 5.2.

Avant l'arrivée de npx, il était nécessaire d'installer des packages en tant que dépendance pour pouvoir les utiliser dans un projet.

Grâce à lui, il est maintenant possible d'exécuter des packages sans devoir les installer de manière permanente.

Comment fonctionne npx ?

Lorsque vous utilisez npx pour exécuter un package, celui-ci vérifie d'abord s'il existe déjà dans votre projet ou s'il est installé globalement :

S'il existe, il l'exécute.
S'il n'existe pas, npx l'installe temporairement et l'exécute.

Cela permet de tester des packages sans devoir les installer dans votre projet.

Pour utiliser npx, il suffit de taper la commande npx suivie du nom du package que vous souhaitez exécuter.

Par exemple :

npx mon-super-package

Npx vs npm

Npm est un gestionnaire de packages qui vous aide à installer vos dépendances en lisant votre fichier package.json (à l'instar de yarn et pnpm) à l'aide des commandes :

npm install

npm i

Il permet également d'exécuter des commandes déjà définies dans votre projet.

A la différence de npx, vous pouvez également lancer des commandes de package mais uniquement issues des packages déjà installés.

Et dlx ?

A l'instar de npx, dlx vous permet d'exécuter des packages sans les installer.

Utilsable avec pnpm ou yarn, c'est l'équivalent de npx avec ces packages manager.

Cependant, dlx n'utilisera jamais vos packages locaux pour l'exécution de commande.

Conclusion

Avant la version 5.2. de npm, on devait installer nos packages pour les utiliser.

Aujourd'hui, c'est beaucoup plus simple et ça permet de tester des packages avant de les installer.
On peut également utiliser npx ou dlx pour lancer des scaffolding d'application :

// init d'un projet nuxt
pnpm dlx nuxi init <project-name>

// init d'un projet react
npx create-react-app my-app

Merci d'avoir lu cet article !
Il a été posté initialement sur mon site : https://necraidan.com/blog/npm-npx-dlx

Cover par Jiawei Zhao sur Unsplash

Angular 14 en 3 features

Benjamin Auzanneau — Tue, 07 Jun 2022 21:50:29 +0000

Depuis le 2 juin 2022, la core team Angular a released la version 14 d'Angular.

Voici le top 3 de ce que j'ai retenu :

𝐒𝐭𝐚𝐧𝐝𝐚𝐥𝐨𝐧𝐞 𝐜𝐨𝐦𝐩𝐨𝐧𝐞𝐧𝐭

Les composants autonomes font leur apparition en 𝘥𝘦𝘷𝘦𝘭𝘰𝘱𝘱𝘦𝘳 𝘱𝘳𝘦𝘷𝘪𝘦𝘸.
Plus besoin de créer un NgModule pour pouvoir importer/utiliser votre composant.

Disponible également pour les directives et les pipes.

https://angular.io/guide/standalone-components
https://blog.ninja-squad.com/2022/05/12/a-guide-to-standalone-components-in-angular/

𝐂𝐨𝐦𝐩𝐢𝐥𝐞𝐫 𝐚𝐧𝐝 𝐩𝐫𝐨𝐭𝐞𝐜𝐭𝐞𝐝 𝐦𝐞𝐦𝐛𝐞𝐫𝐬

Vous le savez déjà mais jusqu'à Angular 14, on ne pouvait mettre que des 𝘢𝘵𝘵𝘳𝘪𝘣𝘶𝘵𝘴 de classe public dans les 𝘵𝘦𝘮𝘱𝘭𝘢𝘵𝘦𝘴.
On peut désormais ajouter des attributs 𝐩𝐫𝐨𝐭𝐞𝐜𝐭𝐞𝐝 !

𝐓𝐲𝐩𝐞𝐝 𝐀𝐧𝐠𝐮𝐥𝐚𝐫 𝐅𝐨𝐫𝐦𝐬

Le typage strict des 𝘙𝘦𝘢𝘤𝘵𝘪𝘷𝘦 𝘍𝘰𝘳𝘮𝘴 arrive enfin !

https://angular.io/guide/typed-forms

𝐁𝐨𝐧𝐮𝐬 : 𝐂𝐡𝐚𝐧𝐠𝐞 𝐝𝐞𝐭𝐞𝐜𝐭𝐢𝐨𝐧 𝐛𝐲 Minko Gechev

En bonus, Minko vous propose de revoir les optimisations que l'on peut faire avec le changement détection et l'optimisation du runtime.

By the way, Thanks Minko Gechev for your video !

Vous voulez creuser un peu plus sur les nouveautés ?
C'est par ici :

https://blog.angular.io/angular-v14-is-now-available-391a6db736af
https://blog.ninja-squad.com/2022/06/02/what-is-new-angular-14.0/
(Merci la Ninja Squad)

Merci d'avoir lu cet article !
Il a été posté initialement sur mon site : https://necraidan.com/blog/angular-14-3-features

J'anime également un podcast sur le front-end :
https://anchor.fm/front-end-chronicles

ou directement sur spotify pour le dernier épisode :

A quoi servent les peerDependencies dans le package.json ?

Benjamin Auzanneau — Thu, 20 May 2021 07:51:41 +0000

Lors d'une installation npm ou bien de la lecture d'un package.json, vous avez sans doute remarqué qu'il y avait deux grands groupes de dépendances : les dependencies et les devDependencies.

Le premier représente les dépendances directs de votre projet (ce dont on a besoin pour que cela fonctionne).

Le second représente ce qui entoure votre projet dans sa phase de développement (les outils qui vont permettre à celui-ci de fonctionner/builder/deployer par exemple).

Il existe un troisième groupe à ne pas négliger : les peerDependencies

Dans cet article, on va vous expliquez ce que peut apporter le champs peerDependencies dans votre package.json.

Ça sert à quoi les `peerDependencies` ?

En ajoutant une dependencie dans cette section de votre package.json, vous indiquez :

Que votre code est compatible avec la version de la dependencie indiquée
Si la version de la dependencie n'existe pas dans les node_modules, on va lever un warning
Si la version de la dependencie existe dans les node_modules, on ne fait rien

Cas d'école

Ce cas est valable pour une version npm > 3 et < 7 (on en parle à la fin de l'article).

Prenons un projet qui a pour dépendance a :

// Extrait du package.json de notre projet
{
  //...
  "dependencies": {
    "a": "1.0.0"
  }
}

Si on se penche sur le package.json de la dépendance a nous avons :

// Extrait du package.json de la dépendance a
{
  //...
  "peerDependencies": {
    "b": "^1.0.0"
  }
}

Un warning assez commun

Il vous ait peut-être arrivé de tomber sur ce genre de message :

npm WARN react-datepicker@0.25.0 requires a peer of react@^0.14.0 but none was installed.

Comme indiqué plus haut, ce warning vous informe qu'un package possède une dependencie qui n'est pas installée (non présente dans vos node_modules).

Dans notre cas d'école, on va avoir :

npm WARN a@1.0.0 requires a peer of b@^1.0.0 but none was installed.

C'est donc à vous d'installer cette dépendance en l'ajoutant aux dependencies de votre projet

// Extrait du package.json de notre projet
{
  //...
  "dependencies": {
    "a": "1.0.0",
    "b": "1.0.0"
  }
}

Les versions installées doivent être compatibles entres elles en suivant la gestion sémantique de version (le semver pour les initié·e·s 👌).

Nouveauté de la version 7 de `npm`

Assez récente, cette nouvelle version vient changer cette façon de fonctionner.

Comme mentionné plus haut, en fonction de la version de npm, le comportement sera différent au niveau de l'installation des dependencies :

Avant la version 3.0 : npm installait automatiquement les peerDependencies mais cela occasionnait de nombreux problèmes (de versions...)
Entre 3 et 7 : npm lève un warning vous informant qu'il y a des peerDependencies à installer vous même
7 : npm réinstalle automatiquement les peerDependencies. Une grosse refactorisation du code interne a permit de résoudre les problèmes rencontrés avant la version 3

Conclusion

La compréhension du concept est finalement assez simple à saisir, je vous encourage à aller jeter un œil à l'intérieur des packages que vous utilisez !

Quant à la montée en version vers npm 7, elle permet de nous facilité la vie sur la gestion de ces dependencies en nous évitant de nous faire des nœuds au cerveau.

Merci d'avoir lu cet article !
Il a été posté initialement sur le blog de @younup_it :
https://www.younup.fr/blog/a-quoi-servent-les-peerdependencies-dans-le-package-json

Cover par Jackie Zhao sur Unsplash

nvm ou comment travailler avec plusieurs versions de Node.js

Benjamin Auzanneau — Thu, 07 Jan 2021 08:55:35 +0000

Aujourd'hui, il est assez commun de devoir installer Node.js pour faire fonctionner un projet.

L'installation étant assez simple, la modification et/ou la mise à jour de la version de Node.js installée sur votre système l'est beaucoup moins

Dans cet article on va parler d'une solution qui va nous permettre de changer simplement de version Node.js à la volée : nvm

Qu'est-ce que nvm ?

L'acronyme de nvm signifie : Node Version Manager.

Comment on l'a dit précédemment, cet outil va nous permettre de manager plusieurs version de Node.js.

Disponible uniquement sur environnement Unix de base, un fork a été réalisé pour Windows.

Installation Unix

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.36.0/install.sh | bash

Vous pouvez également vous référer au readme pour des informations plus complètes sur l'installation Unix

Installation Windows

Pour Windows, il faut se tourner vers le fork et installer la dernière release en date.

Néanmoins, même si c'est fonctionnel, le projet n'a pas été mis à jour depuis Août 2018.

Exemples d'utilisation

Voici un exemple d'installation d'une version de Node.js :

nvm install 14.14.0

En changeant le numéro de version, vous pourrez installer la version que vous souhaitez.

Pour connaitre la liste des versions de Node.js installées :

nvm list
    14.14.0
   *14.11.0 (Currently using 64-bit executable)

Enfin, voici la commande pour pouvoir utiliser une version spécifique installée

nvm use 14.14.0

Vos différentes variables d'environnement vont changer et pointer sur votre version de Node.js voulue.

Et... c'est tout !

Des alternatives existent

Même si ces alternatives restent confidentielles à côté de nvm, elles ne déméritent pas d'exister

n : la différence notable avec nvm est l'installation des packages globales. Dans nvm, les packages globales sont séparés par version de Node.js ce qui n'est pas le cas avec n
nvs : propose un interpréteur plus évolué et la possibilité de choisir également ChakraCore.

Depuis l'annonce de Microsoft de passer sur le même moteur de rendu que Chromium (le moteur V8, celui sur lequel est basé Node.js), Microsoft ne proposera plus de patch de sécurité sur ChakraCore à partir du 9 Mars 2021

One more thing

L'un des points fort de l'utilisation de nvm quand vous êtes sur un environnement Unix est de pouvoir placer un .nvmrc à la racine de votre projet.
nvm changera automatiquement de version quand vous naviguerez dans votre dossier de projet !

Conclusion

Pour du multi-projet ou pour votre poste de travail, l'utilisation de nvm va vous permettre de pérenniser vos versions de Node.js.
A utiliser sans modération !

Merci d'avoir lu cet article !
Il a été posté initialement sur le blog de @younup_it :
https://www.younup.fr/blog/nvm-ou-comment-travailler-avec-plusieurs-versions-de-node-js

Comment publier son premier package npm

Benjamin Auzanneau — Wed, 11 Nov 2020 10:30:31 +0000

Dans cet article nous allons vous montrer comment nous pouvons simplement publier un package npm.

Pour cela, nous allons utiliser un projet support, notre carte de visite Younup !

Le projet

L'idée du projet est de pouvoir afficher une carte de visite dans un terminal en exécutant notre package avec la commande suivante :

npx younup

Le code source du projet est disponible sur notre github

Au passage, on parle de la commande npx dans notre blog

Compte et connexion

La première étape est de créer un compte npm (pour cela rendez-vous ici).

Ensuite, vous devez vous connecter à votre compte en ligne de commande :

npm login

Le prompt va vous demander plusieurs informations :

npm login
Username: younup
Password:
Email: (this IS public) helloyou@younup.fr
Logged in as younup on https://registry.npmjs.org/.

Init du package

Si vous démarrez de 0, il faudra init votre package.

npm init

Après quelques questions, un fichier package.json est créé.
Il contient les informations essentiels pour pouvoir publier votre projet.

Voici le package.json de notre projet carte de visite :

{
    "name": "younup",
    "version": "1.0.0",
    "description": "The Younup Card",
    "main": "./bin/card.js",
    "bin": {
        "younup": "./bin/card.js"
    },
    "scripts": {
        "start": "node ./bin/card.js"
    },
    "repository": {
        "type": "git",
        "url": "git+https://github.com/Younup/card.git"
    },
    "keywords": [
        "younup",
        "npx",
        "card",
        "npx card"
    ],
    "author": "Benjamin Auzanneau <b.auzanneau@younup.fr>",
    "license": "MIT",
    "dependencies": {
        "boxen": "^4.2.0",
        "chalk": "^3.0.0"
    }
}

Publication

Le seul point noir que vous allez peut-être rencontrer en publiant, c'est la collision de nom.
Vous ne pouvez pas avoir un projet publié sur npm qui possède le même name que dans votre package.json.

Pour pouvoir publiez votre projet, il suffit de taper la commande suivante :

npm publish

La console affichera votre déploiement en temps réel :

npm notice
npm notice package: younup@1.0.0   
npm notice === Tarball Contents === 
npm notice 623B  package.json
npm notice 98B   .prettierrc
npm notice 1.1kB LICENSE
npm notice 115B  README.md
npm notice 1.2kB ascii/logo.js
npm notice 2.4kB bin/card.js
npm notice === Tarball Details ===
npm notice name:          younup
npm notice version:       1.0.0
npm notice package size:  2.7 kB
npm notice unpacked size: 7.4 kB
npm notice shasum:        2631976b0f4b3fe836ef945213d6d7c95c6ab7af
npm notice integrity:     sha512-ObT18M8pTkBz4[...]vuSXDf1lRcVbA==
npm notice total files:   6
npm notice
+ younup@1.0.0

Le projet est maintenant accessible au téléchargement sur le registry de npm

La carte de visite Younup

Maintenant que notre projet est accessible à tous, il est possible de l'exécuter ou de l'installer dans votre projet en tant que dépendance.

En ce qui concerne la carte de visite, elle n'existe que pour être exécuté dans votre terminal :

Merci d'avoir lu cet article !
Il a été posté initialement sur le blog de @younup_it :
https://www.younup.fr/blog/comment-publier-son-premier-package-npm

Quick tip about setTimeout function

Benjamin Auzanneau — Wed, 09 Sep 2020 10:01:28 +0000

In JavaScript, we have the event loop.

So, without Web Workers, JavaScript is single-threaded, non-blocking, asynchronous, concurrent language.

What can I do with the setTimeout function ?
I can launch the execution of a part of your code after a delay.

The delay may be longer than intended.

setTimeout(() => console.log('After the delay'), 5000);

console.log('Before the delay');

// Printed => 'Before the delay'
// After ≈ 5 secondes => 'After the delay'

One more thing

Sometimes you can see this kind of code.

setTimeout(() => {someHTMLNode.style.color = 'yellow'}, 0)

We are manipulating a property of a node element (it's a DOM element).
But the DOM is not ready, someHTMLNode doesn't exist.

ThesetTimeout(fn, 0) is a workaround, we can delay our affection after the DOM rendering !

That's it, make good use of it !

I'm not a native English speaker so, thanks in advance if you want to improve my article with correct syntax/grammar/sentences.

I can accept all kind remarks :)

Cover by Icons8 Team on Unsplash

Merci d'avoir lu cet article !
Il a été posté initialement sur mon site : https://necraidan.com/blog/back-to-basics-set-timeout

Quick tip about array and unique values

Benjamin Auzanneau — Tue, 08 Sep 2020 07:18:31 +0000

The naive way to do this is to check each value, add it to a data structure, and detect if we haven't added it before.

The naive way

const namesFromAnotherGalaxy= ['Luke', 'Leia', 'Obi-Wan', 'Luke', 'Obi-Wan'];

function naiveWay(names) {
  const unique = {};
  names.forEach((i) => {
    if(!unique[i]) {
      unique[i] = true;
    }
  });
  return Object.keys(unique );
}

naiveWay(namesFromAnotherGalaxy); // ['Luke', 'Leia', 'Obi-Wan']

Another simple way of thinking to get unique values from an array is to use the filter method to filter out the repetitive values.

The filter way

const duelists = ['Yugi', 'Kaiba', 'Yugi', 'Joey', 'Joey'];

const filterWay = (names) => names.filter((value, index) => names.indexOf(value) === index)

filterWay(duelists); // ['Yugi', 'Kaiba', 'Joey'];

But with the new native Set object we can do something smoother and easier.

This is the way

const thisIsTheWay= [...new Set(['kobe', 'kobe', 'michael', 23, 24, 23])]; // ['kobe', 'michael', 23, 24]

That's it, make good use of it !

I'm not a native English speaker so, thanks in advance if you want to improve my article with correct syntax/grammar/sentences.

I can accept all kind remarks :)

Cover by Faris Mohammed on Unsplash

Quick tip about function vs function*

Benjamin Auzanneau — Mon, 07 Sep 2020 13:35:21 +0000

What is function * ?

It's generator function which returns a Generator object.
Generators are intricately linked with iterators.

But what is a generator function ?

It's a function that can stop midway and then continue from where it stopped !

function * generatorExample() {
  let counter = 0;
  yield `First step ! ${counter}`;
  counter++;
  yield `Second step ! ${counter}`;
  counter++;
  console.log('No yield, the function is done');
}

const generator = generatorExample();
console.log(generator.next().value); // First step ! 1
console.log(generator.next().value); // Second step ! 2
console.log(generator.next().value); // No yield, the function is done

The Generator object offers a next() function that you can call to go further into the next step of the generator.

You can check MDN for more information.

That's it, make good use of it !

I'm not a native English speaker so, thanks in advance if you want to improve my article with correct syntax/grammar/sentences.

I can accept all kind remarks :)

Cover by Wolfgang Rottmann on Unsplash

Quick tip about TypeScript and why to avoid these types

Benjamin Auzanneau — Fri, 04 Sep 2020 08:09:25 +0000

Avoid the non-primitive Number, String, Boolean, Object, and Symbol types in TypeScript.
All of them refer to non-primitive reference types.
Instead, prefer the corresponding primitive types.

let textToCheck: String = 'text';
console.log(typeof textToCheck); // 'string'
console.log(textToCheck === 'text'); // true

textToCheck = new String('text');
console.log(typeof textToCheck); // 'object'
console.log(textToCheck === 'text'); // false

It's easy to failed your equality check with them.

There is also a performance part that I will not detail here. I recommend this article from mozilla which makes a performance comparison between a literal string and its object version in JavaScript.

That's it, make good use of it !

I'm not a native English speaker so, thanks in advance if you want to improve my article with correct syntax/grammar/sentences.

I can accept all kind remarks :)

Cover by JC Dela Cuesta on Unsplash

Forem: Benjamin Auzanneau

Le package.json

Le manifeste

L'origine

Les attributs

Les types de dépendances

Focus sur les peerDependencies

Le lockfile de npm : le package-lock.json

Ce qu’on trouve dedans

npm install vs npm ci

Cas avancés

Conclusion

Sources

Guide du SemVer avec npm

Le SemVer, c’est quoi ?

Le symbole ^ : “jusqu’à la prochaine release majeure”

Le symbole ~ : “patchs uniquement”

Les symboles >, >=, <, <=, = : comparateurs

Le symbole - : inclusif

Le symbole || : combiner des ensembles

Le dist-tag : latest

Bonus : x, * et les pré-releases -alpha, -beta

Conclusion

Sources

Le SemVer

Aux origines

Une convention

Le cœur de la convention : la notion d’API publique

Le cas particulier des versions 0.x

Conclusion

Sources

Npx, c'est quoi ?

Comment fonctionne npx ?

Npx vs npm

Et dlx ?

Conclusion

Angular 14 en 3 features

A quoi servent les peerDependencies dans le package.json ?

Ça sert à quoi les peerDependencies ?

Cas d'école

Un warning assez commun

Nouveauté de la version 7 de npm

Conclusion

nvm ou comment travailler avec plusieurs versions de Node.js

Qu'est-ce que nvm ?

Installation Unix

Installation Windows

Exemples d'utilisation

Des alternatives existent

One more thing

Conclusion

Comment publier son premier package npm

Le projet

Compte et connexion

Init du package

Publication

La carte de visite Younup

Quick tip about setTimeout function

One more thing

Quick tip about array and unique values

The naive way

The filter way

This is the way

Quick tip about function vs function*

Quick tip about TypeScript and why to avoid these types

Focus sur les `peerDependencies`

`npm install` vs `npm ci`

Le `SemVer`, c’est quoi ?

Le symbole `^` : “jusqu’à la prochaine release majeure”

Le symbole `~` : “patchs uniquement”

Les symboles `>`, `>=`, `<`, `<=`, `=` : comparateurs

Le symbole `-` : inclusif

Le symbole `||` : combiner des ensembles

Le dist-tag : `latest`

Bonus : `x`, `*` et les pré-releases `-alpha`, `-beta`

Le cas particulier des versions `0.x`

Ça sert à quoi les `peerDependencies` ?

Nouveauté de la version 7 de `npm`