One place for hosting & domains

      modules

      Comment utiliser les modules Node.js avec npm et package.json


      L’auteur a choisi le Open Internet/Free Speech Fund pour recevoir un don dans le cadre du programme Write for DOnations.

      Introduction

      Grâce à des caractéristiques telles que ses bonnes performances d’entrée/sortie (E/S) et sa syntaxe JavaScript bien connue, Node.js est rapidement devenu un environnement d’exécution populaire pour le développement Web back-end. Mais à mesure que l’intérêt grandit, de plus grandes applications sont construites, et la gestion de la complexité de la base de code et de ses dépendances devient plus difficile. Node.js organise cette complexité à l’aide de modules, qui sont des fichiers JavaScript individuels contenant des fonctions ou des objets pouvant être utilisés par d’autres programmes ou modules. Un ensemble d’un ou plusieurs modules est communément appelé paquet, et ces paquets sont eux-mêmes organisés par des gestionnaires de paquets.

      Node.js Package Manager (npm) est le gestionnaire de paquets par défaut et le plus populaire dans l’écosystème Node.js. Il est principalement utilisé pour installer et gérer des modules externes dans un projet Node.js. Il est également couramment utilisé pour installer une large gamme d’outils CLI et exécuter des scripts de projet. npm suit les modules installés dans un projet avec le fichier package.json, qui réside dans le répertoire d’un projet et contient :

      • Tous les modules nécessaires à un projet et leurs versions installées
      • Toutes les métadonnées d’un projet, telles que l’auteur, la licence, etc.
      • Les scripts pouvant être exécutés pour automatiser des tâches dans le cadre du projet

      À mesure que vous créez des projets Node.js plus complexes, la gestion de vos métadonnées et dépendances avec le fichier package.json vous fournira des builds plus prévisibles, puisque toutes les dépendances externes restent les mêmes. Le fichier gardera automatiquement la trace de ces informations ; si vous pouvez modifier le fichier directement pour mettre à jour les métadonnées de votre projet, vous aurez rarement besoin d’interagir directement avec lui pour gérer les modules.

      Dans ce tutoriel, vous allez gérer des paquets avec npm. La première étape consistera à créer et comprendre le fichier package.json. Vous l’utiliserez ensuite pour garder une trace de tous les modules que vous installez dans votre projet. Enfin, vous listerez les dépendances de vos paquets, mettrez à jour vos paquets, désinstallerez vos paquets et effectuerez un audit pour trouver des failles de sécurité dans vos paquets.

      Conditions préalables

      Pour suivre ce tutoriel, vous aurez besoin de :

      Étape 1 — Création d’un fichier package.json

      Nous commençons ce tutoriel en configurant le projet exemple : un module Node.js fictif locator qui obtient l’adresse IP de l’utilisateur et renvoie le pays d’origine. Vous ne coderez pas le module dans ce tutoriel. Cependant, les paquets que vous gérez seraient pertinents si vous les développiez.

      Tout d’abord, vous allez créer un fichier package.json pour stocker des métadonnées utiles sur le projet et vous aider à gérer les modules Node.js dépendants du projet. Comme le suffixe le suggère, il s’agit d’un fichier JSON (JavaScript Object Notation). JSON est un format standard utilisé pour le partage, basé sur des objets JavaScript et constitué de données stockées sous forme de paires clé-valeur. Si vous souhaitez en savoir plus sur JSON, lisez notre article Introduction à JSON.

      Comme un fichier package.json contient de nombreuses propriétés, il peut être lourd à créer manuellement, sans copier et coller un modèle provenant d’un autre endroit. Pour faciliter les choses, npm fournit la commande init. Il s’agit d’une commande interactive qui vous pose une série de questions et crée un fichier package.json en fonction de vos réponses.

      Utilisation de la commande init

      Commencez par configurer un projet afin de vous entraîner à gérer les modules. Dans votre shell, créez un nouveau dossier appelé locator :

      Entrez ensuite dans le nouveau dossier :

      Maintenant, initialisez l’invite interactive en entrant :

      Remarque : si votre code doit utiliser Git pour le contrôle de version, créez d’abord le référentiel Git, puis exécutez npm init. La commande comprend automatiquement qu’elle se trouve dans un dossier compatible avec Git. Si un référentiel distant Git est défini, il remplit automatiquement les champs repository, bugs et homepage de votre fichier package.json. Si vous avez initialisé le référentiel après avoir créé le fichier package.json, vous devrez ajouter ces informations vous-même. Pour en savoir plus sur le contrôle de version de Git, consultez notre Introduction à Git : installation, utilisation et branches.

      Vous recevrez le résultat suivant :

      Output

      This utility will walk you through creating a package.json file. It only covers the most common items, and tries to guess sensible defaults. See `npm help json` for definitive documentation on these fields and exactly what they do. Use `npm install <pkg>` afterwards to install a package and save it as a dependency in the package.json file. Press ^C at any time to quit. package name: (locator)

      Vous serez d’abord invité à indiquer la valeur name (nom) de votre nouveau projet. Par défaut, la commande suppose qu’il s’agit du nom du dossier dans lequel vous vous trouvez. Les valeurs par défaut de chaque propriété sont indiquées entre parenthèses (). Puisque la valeur par défaut pour name fonctionnera pour ce tutoriel, appuyez sur ENTER (ENTRÉE) pour l’accepter.

      La prochaine valeur à saisir est version. Tout comme name, ce champ est obligatoire si votre projet doit être partagé avec d’autres dans le dépôt de paquets npm.

      Remarque : les paquets Node.js doivent suivre le guide de Semantic Versioning (semver). Par conséquent, le premier chiffre sera le numéro de version MAJOR qui ne change que lorsque l’API change. Le deuxième chiffre sera la version MINOR qui change lorsque des fonctionnalités sont ajoutées. Le dernier chiffre sera la version PATCH qui change lorsque les bugs sont corrigés.

      Appuyez sur ENTER, de sorte que la version par défaut est acceptée.

      Le champ suivant est description, une chaîne utile pour expliquer ce que fait votre module Node.js. Notre projet locator fictif permettrait d’obtenir l’adresse IP de l’utilisateur et de renvoyer le pays d’origine. Finds the country of origin of the incoming request (Détermine le pays d’origine de la requête entrante) serait une description appropriée, saisissez donc un texte de ce type et appuyez sur ENTER. La description est très utile lorsque les gens recherchent votre module.

      L’invite suivante vous demandera la valeur du point d’entrée entry point. Si quelqu’un installe et requires (exige) votre module, ce que vous définissez dans entry point sera la première partie de votre programme qui sera chargée. La valeur doit être l’emplacement relatif d’un fichier JavaScript, et sera ajoutée à la propriété main du package.json. Appuyez sur ENTER pour conserver la valeur par défaut.

      Remarque : la plupart des modules ont un fichier index.js comme point d’entrée principal. C’est la valeur par défaut pour la propriété main d’un package.json, qui est le point d’entrée pour les modules npm. S’il n’y a pas de package.json, Node.js essaiera de charger index.js par défaut.

      Ensuite, il vous sera demandé une test command, un script exécutable ou une commande pour exécuter les tests de votre projet. Dans de nombreux modules populaires de Node.js, les tests sont écrits et exécutés avec Mocha, Jest, Jasmine ou d’autres frameworks de test. Puisque cet article ne couvre pas les tests, laissez cette option vide pour l’instant et appuyez sur ENTER pour continuer.

      La commande init demandera alors le référentiel GitHub du projet. Vous n’en utiliserez pas dans cet exemple donc laissez-le également vide.

      Après l’invite pour le référentiel, la commande demande des keywords (mots clés). Cette propriété est un tableau de chaînes de caractères contenant des termes utiles que les gens peuvent utiliser pour trouver votre référentiel. Il est préférable d’avoir un petit groupe de mots vraiment pertinents pour votre projet, afin que la recherche puisse être plus ciblée. Inscrivez ces mots clés sous forme de chaîne de caractères, en séparant chaque valeur par une virgule. Pour cet exemple de projet, tapez ip,geo,country (ip,géo,pays) à l’invite. Le package.json final comportera trois éléments dans le tableau keywords.

      Le champ suivant dans l’invite est author (auteur). Ceci est utile pour les utilisateurs de votre module qui veulent entrer en contact avec vous. Par exemple, si quelqu’un découvre un exploit dans votre module, il peut l’utiliser pour signaler le problème afin que vous puissiez le résoudre. Le champ author est une chaîne de caractères au format suivant : "Name <Email> (Website)". Par exemple, "Sammy <sammy@your_domain> (https://your_domain)" est un auteur valide. L’adresse e-mail et les données du site Web sont facultatives : un auteur valide peut être un simple nom. Ajoutez vos coordonnées en tant qu’auteur et confirmez avec ENTER.

      Enfin, la license (licence) vous sera demandée. Elle détermine les autorisations et les limitations légales pour les utilisateurs de votre module. De nombreux modules Node.js sont open source, donc npm fixe la valeur par défaut à ISC.

      À ce stade, vous devez examiner vos options de licence et décider ce qui convient le mieux à votre projet. Pour plus d’informations sur les différents types de licences open source, consultez cette liste de licences dOpen Source Initiative. Si vous ne souhaitez pas fournir de licence pour un référentiel privé, vous pouvez taper UNLICENSED à l’invite. Pour cet échantillon, utilisez la licence ISC par défaut, et appuyez sur ENTER pour terminer ce processus.

      La commande init affichera maintenant le fichier package.json qu’elle va créer. Il ressemblera à cela :

      Output

      About to write to /home/sammy/locator/package.json: { "name": "locator", "version": "1.0.0", "description": "Finds the country of origin of the incoming request", "main": "index.js", "scripts": { "test": "echo "Error: no test specified" && exit 1" }, "keywords": [ "ip", "geo", "country" ], "author": "Sammy <sammy@your_domain> (https://your_domain)", "license": "ISC" } Is this OK? (yes)

      Une fois que les informations correspondent à ce que vous voyez ici, appuyez sur ENTER pour terminer ce processus et créer le fichier package.json. Grâce à ce fichier, vous pouvez conserver une trace des modules que vous installez pour votre projet.

      Maintenant que vous avez votre fichier package.json, vous pouvez tester l’installation de modules lors de l’étape suivante.

      Étape 2 – Installation de modules

      Il est courant dans le développement de logiciels d’utiliser des bibliothèques externes pour effectuer des tâches auxiliaires dans les projets. Cela permet au développeur de se concentrer sur la logique commerciale et de créer l’application plus rapidement et plus efficacement.

      Par exemple, si notre exemple de module locator doit faire une requête API externe pour obtenir des données géographiques, nous pourrions utiliser une bibliothèque HTTP pour faciliter cette tâche. Comme notre objectif principal est de renvoyer des données géographiques pertinentes à l’utilisateur, nous pourrions installer un paquet qui nous facilite les requêtes HTTP au lieu de réécrire ce code nous-mêmes, une tâche qui dépasse le cadre de notre projet.

      Examinons cet exemple. Dans votre application locator, vous utiliserez la bibliothèque axios, qui vous aidera à effectuer des requêtes HTTP. Installez-la en entrant ce qui suit dans votre shell :

      Vous commencez cette commande avec npm install, qui va installer le paquet (pour être bref, vous pouvez utiliser npm i). Vous listerez ensuite les paquets que vous voulez installer, séparés par une espace. Dans ce cas, il s’agit d’axios. Enfin, vous terminez la commande avec le paramètre optionnel --save, qui spécifie qu’axios sera sauvegardé comme une dépendance du projet.

      Lorsque la bibliothèque sera installée, vous verrez une sortie similaire à ce qui suit :

      Output

      ... + axios@0.19.0 added 5 packages from 8 contributors and audited 5 packages in 0.764s found 0 vulnerabilities

      Maintenant, ouvrez le fichier package.json, en utilisant l’éditeur de texte de votre choix. Ce tutoriel utilisera nano :

      Vous verrez une nouvelle propriété, comme surligné ci-dessous :

      locator/package.json

      {
        "name": "locator",
        "version": "1.0.0",
        "description": "Finds the country of origin of the incoming request",
        "main": "index.js",
        "scripts": {
          "test": "echo "Error: no test specified" && exit 1"
        },
        "keywords": [
          "ip",
          "geo",
          "country"
        ],
        "author": "Sammy sammy@your_domain (https://your_domain)",
        "license": "ISC",
        "dependencies": {
          "axios": "^0.19.0"
        }
      }
      

      L’option --save a indiqué à npm de mettre à jour le package.json avec le module et la version qui viennent d’être installés. C’est très bien, car les autres développeurs travaillant sur vos projets peuvent facilement voir quelles sont les dépendances externes nécessaires.

      Remarque : vous avez peut-être remarqué le ^ avant le numéro de version pour la dépendance axios. Rappelez-vous que la version sémantique est constituée de trois chiffres : MAJOR, MINOR et PATCH. Le symbole ^ signifie que toute version MINOR ou PATCH supérieure satisferait à cette contrainte de version. Si vous voyez ~ au début d’un numéro de version, alors seules les versions PATCH supérieures satisfont à la contrainte.

      Lorsque vous avez terminé d’examiner le fichier package.json, quittez-le.

      Dépendances de développement

      Les paquets qui sont utilisés pour le développement d’un projet mais pas pour le construire ou le faire fonctionner en production sont appelés dépendances de développement. Ces dépendances ne sont pas nécessaires pour que votre module ou application fonctionne en production, mais peuvent être utiles lors de l’écriture du code.

      Par exemple, il est courant que les développeurs utilisent des linters pour s’assurer que leur code suit les meilleures pratiques et pour garder un style cohérent. Bien que cela soit utile pour le développement, cela ne fait qu’augmenter la taille du module distribué sans apporter d’avantage tangible lorsqu’il est déployé en production.

      Installez un linter comme dépendance de développement pour votre projet. Essayez cela dans votre shell :

      • npm i eslint@6.0.0 --save-dev

      Dans cette commande, vous avez utilisé l’indicateur --save-dev. Cela permettra d’enregistrer eslint comme une dépendance qui n’est nécessaire que pour le développement. Notez également que vous avez ajouté @6.0.0 à votre nom de dépendance. Lorsque les modules sont mis à jour, ils sont marqués avec une version. Le @ indique à npm de rechercher une balise spécifique du module que vous installez. Sans balise spécifique, npm installe la dernière version marquée. Ouvrez à nouveau package.json :

      Cela montrera ce qui suit :

      locator/package.json

      {
        "name": "locator",
        "version": "1.0.0",
        "description": "Finds the country of origin of the incoming request",
        "main": "index.js",
        "scripts": {
          "test": "echo "Error: no test specified" && exit 1"
        },
        "keywords": [
          "ip",
          "geo",
          "country"
        ],
        "author": "Sammy sammy@your_domain (https://your_domain)",
        "license": "ISC",
        "dependencies": {
          "axios": "^0.19.0"
        },
        "devDependencies": {
          "eslint": "^6.0.0"
        }
      }
      

      eslint a été enregistré en tant que devDependencies, avec le numéro de version que vous avez indiqué précédemment. Quittez package.json.

      Fichiers générés automatiquement : node_modules et package-lock.json

      Lorsque vous installez un paquet dans un projet Node.js pour la première fois, npm crée automatiquement le dossier node_modules pour stocker les modules nécessaires à votre projet et le fichier package-lock.json que vous avez examiné précédemment.

      Vérifiez qu’ils se trouvent dans votre répertoire de travail. Dans votre shell, tapez ls et appuyez sur ENTER. Vous verrez la sortie suivante :

      Output

      node_modules package.json package-lock.json

      Le dossier node_modules contient toutes les dépendances installées pour votre projet. Dans la plupart des cas, vous ne devez pas commiter ce référentiel dans votre référentiel à version contrôlée. Au fur et à mesure que vous installez des dépendances, la taille de ce dossier augmentera rapidement. En outre, le fichier package-lock.json conserve une trace des versions exactes installées de manière plus succincte, de sorte qu’il n’est pas nécessaire d’inclure node_modules.

      Alors que le fichier package.json liste les dépendances qui nous indiquent les versions appropriées à installer pour le projet, le fichier package-lock.json garde la trace de toutes les modifications dans package.json ou node_modules et nous indique la version exacte du paquet installé. Vous commitez généralement dans votre référentiel à version contrôlée au lieu de node_modules, car c’est une représentation plus propre de toutes vos dépendances.

      Installation depuis package.json

      Avec vos fichiers package.json et package-lock.json, vous pouvez rapidement mettre en place les mêmes dépendances avant de commencer le développement d’un nouveau projet. Pour le démontrer, remontez d’un niveau dans votre arborescence de répertoires et créez un nouveau dossier nommé cloned_locator au même niveau de répertoire que locator :

      • cd ..
      • mkdir cloned_locator

      Entrez dans votre nouveau répertoire :

      Maintenant, copiez les fichiers package.json et package-lock.json depuis locator vers cloned_locator :

      • cp ../locator/package.json ../locator/package-lock.json .

      Pour installer les modules nécessaires à ce projet, entrez :

      npm vérifiera la présence d’un fichier package-lock.json pour installer les modules. Si aucun fichier lock n’est disponible, npm lira le fichier package.json pour déterminer les installations. Il est généralement plus rapide d’installer à partir de package-lock.json, puisque le fichier lock contient la version exacte des modules et de leurs dépendances, ce qui signifie que npm n’a pas besoin de passer du temps à trouver une version appropriée à installer.

      Lors du déploiement en production, vous voudrez peut-être ignorer les dépendances de développement. Rappelez-vous que les dépendances de développement sont stockées dans la section devDependencies de package.json, et n’ont aucun impact sur le fonctionnement de votre application. Lorsque vous installez des modules dans le cadre du processus CI/CD pour déployer votre application, omettez les dépendances dev en exécutant :

      L’indicateur --production omet la section devDependencies pendant l’installation. Pour l’instant, restez fidèle à votre modèle de développement.

      Avant de passer à la section suivante, revenez au dossier locator :

      Installations globales

      Jusqu’à présent, vous avez installé des modules npm pour le projet locator. npm vous permet également d’installer des paquets de façon globale. Cela signifie que le paquet est disponible pour votre utilisateur dans l’ensemble du système, comme toute autre commande shell. Cette capacité est utile pour les nombreux modules Node.js qui sont des outils CLI.

      Par exemple, vous pouvez vouloir parler sur votre blog du projet locator sur lequel vous travaillez actuellement. Pour ce faire, vous pouvez utiliser une bibliothèque comme Hexo pour créer et gérer le blog de votre site Web statique. Installez la CLI d’Hexo de façon globale comme ceci :

      Pour installer un paquet de façon globale, vous ajoutez l’indicateur -g à la commande.

      Remarque : si vous obtenez une erreur de permission en essayant d’installer ce paquet globalement, il est possible que votre système exige des privilèges de super utilisateur pour exécuter la commande. Essayez à nouveau avec sudo npm i hexo-cli -g.

      Vérifiez que le paquet a été installé avec succès en entrant :

      Vous verrez une sortie semblable à :

      Output

      hexo-cli: 2.0.0 os: Linux 4.15.0-64-generic linux x64 http_parser: 2.7.1 node: 10.14.0 v8: 7.6.303.29-node.16 uv: 1.31.0 zlib: 1.2.11 ares: 1.15.0 modules: 72 nghttp2: 1.39.2 openssl: 1.1.1c brotli: 1.0.7 napi: 4 llhttp: 1.1.4 icu: 64.2 unicode: 12.1 cldr: 35.1 tz: 2019a

      Jusqu’à présent, vous avez appris à installer des modules avec npm. Vous pouvez installer des paquets pour un projet localement, soit comme dépendance de production, soit comme dépendance de développement. Vous pouvez également installer des paquets basés sur des fichiers package.json ou package-lock.json préexistants, ce qui vous permet de développer avec les mêmes dépendances que vos pairs. Enfin, vous pouvez utiliser l’indicateur -g pour installer des paquets de façon globale, de sorte que vous puissiez y accéder que vous soyez dans un projet Node.js ou non.

      Maintenant que vous pouvez installer des modules, dans la section suivante vous apprendrez des techniques pour administrer vos dépendances.

      Étape 3 – Gestion de modules

      Un gestionnaire de paquets complet peut faire beaucoup plus qu’installer des modules. npm dispose de plus de 20 commandes relatives à la gestion des dépendances. Au cours de cette étape, vous allez :

      • Lister les modules que vous avez installés.
      • Mettre à jour des modules vers une version plus récente.
      • Désinstaller les modules dont vous n’avez plus besoin.
      • Effectuer un audit de sécurité sur vos modules pour trouver et corriger les failles de sécurité.

      Ces exemples seront réalisés dans votre dossier locator, mais toutes ces commandes peuvent être exécutées globalement en ajoutant l’indicateur -g à la fin de celles-ci, exactement comme vous l’avez fait lors de l’installation globale.

      Lister les modules

      Si vous souhaitez savoir quels modules sont installés dans un projet, il est plus facile d’utiliser la commande list ou ls que de lire directement le fichier package.json. Pour ce faire, entrez :

      Vous verrez un résultat comme celui-ci :

      Output

      ├─┬ axios@0.19.0 │ ├─┬ follow-redirects@1.5.10 │ │ └─┬ debug@3.1.0 │ │ └── ms@2.0.0 │ └── is-buffer@2.0.3 └─┬ eslint@6.0.0 ├─┬ @babel/code-frame@7.5.5 │ └─┬ @babel/highlight@7.5.0 │ ├── chalk@2.4.2 deduped │ ├── esutils@2.0.3 deduped │ └── js-tokens@4.0.0 ├─┬ ajv@6.10.2 │ ├── fast-deep-equal@2.0.1 │ ├── fast-json-stable-stringify@2.0.0 │ ├── json-schema-traverse@0.4.1 │ └─┬ uri-js@4.2.2 ...

      Par défaut, ls montre l’arbre des dépendances dans son intégralité – les modules dont dépend votre projet et les modules dont dépendent vos dépendances. Cela peut être un peu compliqué si vous voulez avoir une vue d’ensemble de ce qui est installé.

      Pour n’imprimer que les modules que vous avez installés sans leurs dépendances, entrez ce qui suit dans votre shell :

      Votre sortie sera :

      Output

      ├── axios@0.19.0 └── eslint@6.0.0

      L’option --depth (profondeur) vous permet de spécifier le niveau d’arborescence des dépendances que vous souhaitez voir. Quand elle est définie sur 0, vous ne voyez que vos dépendances de haut niveau.

      Mettre à jour les modules

      Tenir vos modules npm à jour est une bonne pratique. Vous avez ainsi plus de chances d’obtenir les dernières corrections de sécurité pour un module. Utilisez la commande outdated pour vérifier si des modules peuvent être mis à jour :

      Vous obtiendrez une sortie semblable à la suivante :

      Output

      Package Current Wanted Latest Location eslint 6.0.0 6.7.1 6.7.1 locator

      Cette commande liste d’abord le Package qui est installé et la version Current (actuelle). La colonne Wanted indique quelle version satisfait à votre exigence de version dans package.json. La colonne Latest indique la version la plus récente du module qui a été publiée.

      La colonne Location indique où se trouve le paquet dans l’arborescence des dépendances. La commande outdated a l’indicateur--depth comme ls. Par défaut, la profondeur est 0.

      Il semble que vous puissiez mettre à jour eslint vers une version plus récente. Utilisez la commande update ou up comme ceci :

      La sortie de la commande contiendra la version installée :

      Output

      npm WARN locator@1.0.0 No repository field. + eslint@6.7.1 added 7 packages from 3 contributors, removed 5 packages, updated 19 packages, moved 1 package and audited 184 packages in 5.818s found 0 vulnerabilities

      Si vous voulez mettre à jour tous les modules en une seule fois, vous pouvez entrer :

      Désinstaller les modules

      La commande npm uninstall peut supprimer des modules de vos projets. Cela signifie que le module ne sera plus installé dans le dossier node_modules, ni ne sera vu dans vos fichiers package.json et package-lock.json.

      Supprimer les dépendances d’un projet est une activité normale dans le cycle de vie du développement de logiciels. Une dépendance peut ne pas résoudre le problème comme annoncé, ou ne pas fournir une expérience de développement satisfaisante. Dans ce cas, il peut être préférable de désinstaller la dépendance et de construire son propre module.

      Imaginez qu’axios ne vous apporte pas l’expérience de développement que vous auriez souhaitée pour faire des requêtes HTTP. Désinstallez axios avec la commande uninstall ou un en entrant :

      Votre sortie sera semblable à :

      Output

      npm WARN locator@1.0.0 No repository field. removed 5 packages and audited 176 packages in 1.488s found 0 vulnerabilities

      Il n’est pas dit explicitement qu’axios a été supprimé. Pour vérifier qu’il a été désinstallé, listez à nouveau les dépendances :

      Maintenant, nous voyons seulement qu’eslint est installé :

      Output

      └── eslint@6.7.1

      Cela montre que vous avez réussi à désinstaller le paquet axios.

      Auditer des modules

      npm fournit une commande audit pour mettre en évidence les risques de sécurité potentiels dans vos dépendances. Pour voir l’audit en action, installez une version obsolète du module request en exécutant ce qui suit :

      Lorsque vous installerez cette version obsolète de request, vous remarquerez une sortie semblable à ce qui suit :

      Output

      + request@2.60.0 added 54 packages from 49 contributors and audited 243 packages in 7.26s found 6 moderate severity vulnerabilities run `npm audit fix` to fix them, or `npm audit` for details

      npm vous dit que vos dépendances ont des vulnérabilités. Pour obtenir plus de détails, vérifiez l’ensemble de votre projet avec :

      La commande audit affiche des tableaux de sortie mettant en évidence les failles de sécurité :

      Output

      === npm audit security report === # Run npm install request@2.88.0 to resolve 1 vulnerability ┌───────────────┬──────────────────────────────────────────────────────────────┐ │ Moderate │ Memory Exposure │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Package │ tunnel-agent │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Dependency of │ request │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Path │ request > tunnel-agent │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ More info │ https://npmjs.com/advisories/598 │ └───────────────┴──────────────────────────────────────────────────────────────┘ # Run npm update request --depth 1 to resolve 1 vulnerability ┌───────────────┬──────────────────────────────────────────────────────────────┐ │ Moderate │ Remote Memory Exposure │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Package │ request │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Dependency of │ request │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Path │ request │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ More info │ https://npmjs.com/advisories/309 │ └───────────────┴──────────────────────────────────────────────────────────────┘ ...

      Vous pouvez voir le chemin de la vulnérabilité, et parfois npm vous offre des moyens de la corriger. Vous pouvez exécuter la commande update comme suggéré, ou vous pouvez exécuter la sous-commande fix de audit. Dans votre shell, entrez :

      Vous verrez une sortie semblable à :

      Output

      + request@2.88.0 added 19 packages from 24 contributors, removed 32 packages and updated 12 packages in 6.223s fixed 2 of 6 vulnerabilities in 243 scanned packages 4 vulnerabilities required manual review and could not be updated

      npm a été en mesure de mettre à jour deux des paquets en toute sécurité, réduisant ainsi vos vulnérabilités dans les mêmes mesures. Cependant, vos dépendances présentent encore quatre vulnérabilités. La commande audit fix ne résout pas toujours tous les problèmes. Bien qu’une version d’un module puisse présenter une faille de sécurité, si vous la mettez à jour vers une version avec une API différente, elle pourrait casser le code plus haut dans l’arbre des dépendances.

      Vous pouvez utiliser le paramètre --force pour vous assurer que les vulnérabilités ont disparu, comme ceci :

      Comme nous l’avons déjà mentionné, cela n’est pas recommandé, sauf si vous êtes sûr que cela ne brisera pas la fonctionnalité.

      Conclusion

      Dans ce tutoriel, vous avez réalisé divers exercices pour démontrer comment les modules de Node.js sont organisés en paquets, et comment ces paquets sont gérés par npm. Au sein d’un projet Node.js, vous avez utilisé des paquets npm comme dépendances en créant et en maintenant un fichier package.json – un enregistrement des métadonnées de votre projet, y compris les modules que vous avez installés. Vous avez également utilisé l’outil CLI de npm pour installer, mettre à jour et supprimer des modules, en plus de répertorier l’arborescence des dépendances de vos projets et de vérifier et mettre à jour les modules obsolètes.

      À l’avenir, l’exploitation du code existant en utilisant des modules accélérera le temps de développement, car vous n’aurez pas à répéter les fonctionnalités. Vous serez également en mesure de créer vos propres modules npm, et ceux-ci seront à leur tour gérés par d’autres via des commandes npm. Quant aux prochaines étapes, expérimentez ce que vous avez appris dans ce tutoriel en installant et en testant toute la gamme des paquets disponibles. Voyez ce que l’écosystème fournit pour faciliter la résolution des problèmes. Par exemple, vous pouvez essayer TypeScript, un superset de JavaScript, ou transformer votre site Web en applications mobiles avec Cordova. Si vous souhaitez en savoir plus sur Node.js, consultez nos autres tutoriels Node.js.



      Source link

      How To Use Node.js Modules with npm and package.json


      The author selected the Open Internet/Free Speech Fund to receive a donation as part of the Write for DOnations program.

      Introduction

      Because of such features as its speedy Input/Output (I/O) performance and its well-known JavaScript syntax, Node.js has quickly become a popular runtime environment for back-end web development. But as interest grows, larger applications are built, and managing the complexity of the codebase and its dependencies becomes more difficult. Node.js organizes this complexity using modules, which are any single JavaScript files containing functions or objects that can be used by other programs or modules. A collection of one or more modules is commonly referred to as a package, and these packages are themselves organized by package managers.

      The Node.js Package Manager (npm) is the default and most popular package manager in the Node.js ecosystem, and is primarily used to install and manage external modules in a Node.js project. It is also commonly used to install a wide range of CLI tools and run project scripts. npm tracks the modules installed in a project with the package.json file, which resides in a project’s directory and contains:

      • All the modules needed for a project and their installed versions
      • All the metadata for a project, such as the author, the license, etc.
      • Scripts that can be run to automate tasks within the project

      As you create more complex Node.js projects, managing your metadata and dependencies with the package.json file will provide you with more predictable builds, since all external dependencies are kept the same. The file will keep track of this information automatically; while you may change the file directly to update your project’s metadata, you will seldom need to interact with it directly to manage modules.

      In this tutorial, you will manage packages with npm. The first step will be to create and understand the package.json file. You will then use it to keep track of all the modules you install in your project. Finally, you will list your package dependencies, update your packages, uninstall your packages, and perform an audit to find security flaws in your packages.

      Prerequisites

      To complete this tutorial, you will need:

      Step 1 — Creating a package.json File

      We begin this tutorial by setting up the example project—a fictional Node.js locator module that gets the user’s IP address and returns the country of origin. You will not be coding the module in this tutorial. However, the packages you manage would be relevant if you were developing it.

      First, you will create a package.json file to store useful metadata about the project and help you manage the project’s dependent Node.js modules. As the suffix suggests, this is a JSON (JavaScript Object Notation) file. JSON is a standard format used for sharing, based on JavaScript objects and consisting of data stored as key-value pairs. If you would like to learn more about JSON, read our Introduction to JSON article.

      Since a package.json file contains numerous properties, it can be cumbersome to create manually, without copy and pasting a template from somewhere else. To make things easier, npm provides the init command. This is an interactive command that asks you a series of questions and creates a package.json file based on your answers.

      Using the init Command

      First, set up a project so you can practice managing modules. In your shell, create a new folder called locator:

      Then move into the new folder:

      Now, initialize the interactive prompt by entering:

      Note: If your code will use Git for version control, create the Git repository first and then run npm init. The command automatically understands that it is in a Git-enabled folder. If a Git remote is set, it automatically fills out the repository, bugs, and homepage fields for your package.json file. If you initialized the repo after creating the package.json file, you will have to add this information in yourself. For more on Git version control, see our Introduction to Git: Installation, Usage, and Branches series.

      You will receive the following output:

      Output

      This utility will walk you through creating a package.json file. It only covers the most common items, and tries to guess sensible defaults. See `npm help json` for definitive documentation on these fields and exactly what they do. Use `npm install <pkg>` afterwards to install a package and save it as a dependency in the package.json file. Press ^C at any time to quit. package name: (locator)

      You will first be prompted for the name of your new project. By default, the command assumes it’s the name of the folder you’re in. Default values for each property are shown in parentheses (). Since the default value for name will work for this tutorial, press ENTER to accept it.

      The next value to enter is version. Along with the name, this field is required if your project will be shared with others in the npm package repository.

      Note: Node.js packages are expected to follow the Semantic Versioning (semver) guide. Therefore, the first number will be the MAJOR version number that only changes when the API changes. The second number will be the MINOR version that changes when features are added. The last number will be the PATCH version that changes when bugs are fixed.

      Press ENTER so the default version is accepted.

      The next field is description—a useful string to explain what your Node.js module does. Our fictional locator project would get the user’s IP address and return the country of origin. A fitting description would be Finds the country of origin of the incoming request, so type in something like this and press ENTER. The description is very useful when people are searching for your module.

      The following prompt will ask you for the entry point. If someone installs and requires your module, what you set in the entry point will be the first part of your program that is loaded. The value needs to be the relative location of a JavaScript file, and will be added to the main property of the package.json. Press ENTER to keep the default value.

      Note: Most modules have an index.js file as the main point of entry. This is the default value for a package.json’s main property, which is the point of entry for npm modules. If there is no package.json, Node.js will try to load index.js by default.

      Next, you’ll be asked for a test command, an executable script or command to run your project tests. In many popular Node.js modules, tests are written and executed with Mocha, Jest, Jasmine, or other test frameworks. Since testing is beyond the scope of this article, leave this option empty for now, and press ENTER to move on.

      The init command will then ask for the project’s GitHub Repository. You won’t use this in this example, so leave it empty as well.

      After the repository prompt, the command asks for keywords. This property is an array of strings with useful terms that people can use to find your repository. It’s best to have a small set of words that are really relevant to your project, so that searching can be more targeted. List these keywords as a string with commas separating each value. For this sample project, type ip,geo,country at the prompt. The finished package.json will have three items in the array for keywords.

      The next field in the prompt is author. This is useful for users of your module who want to get in contact with you. For example, if someone discovers an exploit in your module, they can use this to report the problem so that you can fix it. The author field is a string in the following format: "Name <Email> (Website)". For example, "Sammy <sammy@your_domain> (https://your_domain)" is a valid author. The email and website data are optional—a valid author could just be a name. Add your contact details as an author and confirm with ENTER.

      Finally, you’ll be prompted for the license. This determines the legal permissions and limitations users will have while using your module. Many Node.js modules are open source, so npm sets the default to ISC.

      At this point, you would review your licensing options and decide what’s best for your project. For more information on different types of open source licenses, see this license list from the Open Source Initiative. If you do not want to provide a license for a private repository, you can type UNLICENSED at the prompt. For this sample, use the default ISC license, and press ENTER to finish this process.

      The init command will now display the package.json file it’s going to create. It will look similar to this:

      Output

      About to write to /home/sammy/locator/package.json: { "name": "locator", "version": "1.0.0", "description": "Finds the country of origin of the incoming request", "main": "index.js", "scripts": { "test": "echo "Error: no test specified" && exit 1" }, "keywords": [ "ip", "geo", "country" ], "author": "Sammy <sammy@your_domain> (https://your_domain)", "license": "ISC" } Is this OK? (yes)

      Once the information matches what you see here, press ENTER to complete this process and create the package.json file. With this file, you can keep a record of modules you install for your project.

      Now that you have your package.json file, you can test out installing modules in the next step.

      Step 2 — Installing Modules

      It is common in software development to use external libraries to perform ancillary tasks in projects. This allows the developer to focus on the business logic and create the application more quickly and efficiently.

      For example, if our sample locator module has to make an external API request to get geographical data, we could use an HTTP library to make that task easier. Since our main goal is to return pertinent geographical data to the user, we could install a package that makes HTTP requests easier for us instead of rewriting this code for ourselves, a task that is beyond the scope of our project.

      Let’s run through this example. In your locator application, you will use the axios library, which will help you make HTTP requests. Install it by entering the following in your shell:

      You begin this command with npm install, which will install the package (for brevity you can use npm i). You then list the packages that you want installed, separated by a space. In this case, this is axios. Finally, you end the command with the optional --save parameter, which specifies that axios will be saved as a project dependency.

      When the library is installed, you will see output similar to the following:

      Output

      ... + axios@0.19.0 added 5 packages from 8 contributors and audited 5 packages in 0.764s found 0 vulnerabilities

      Now, open the package.json file, using a text editor of your choice. This tutorial will use nano:

      You’ll see a new property, as highlighted in the following:

      locator/package.json

      {
        "name": "locator",
        "version": "1.0.0",
        "description": "Finds the country of origin of the incoming request",
        "main": "index.js",
        "scripts": {
          "test": "echo "Error: no test specified" && exit 1"
        },
        "keywords": [
          "ip",
          "geo",
          "country"
        ],
        "author": "Sammy sammy@your_domain (https://your_domain)",
        "license": "ISC",
        "dependencies": {
          "axios": "^0.19.0"
        }
      }
      

      The --save option told npm to update the package.json with the module and version that was just installed. This is great, as other developers working on your projects can easily see what external dependencies are needed.

      Note: You may have noticed the ^ before the version number for the axios dependency. Recall that semantic versioning consists of three digits: MAJOR, MINOR, and PATCH. The ^ symbol signifies that any higher MINOR or PATCH version would satisfy this version constraint. If you see ~ at the beginning of a version number, then only higher PATCH versions satisfy the constraint.

      When you are finished reviewing package.json, exit the file.

      Development Dependencies

      Packages that are used for the development of a project but not for building or running it in production are called development dependencies. They are not necessary for your module or application to work in production, but may be helpful while writing the code.

      For example, it’s common for developers to use code linters to ensure their code follows best practices and to keep the style consistent. While this is useful for development, this only adds to the size of the distributable without providing a tangible benefit when deployed in production.

      Install a linter as a development dependency for your project. Try this out in your shell:

      • npm i eslint@6.0.0 --save-dev

      In this command, you used the --save-dev flag. This will save eslint as a dependency that is only needed for development. Notice also that you added @6.0.0 to your dependency name. When modules are updated, they are tagged with a version. The @ tells npm to look for a specific tag of the module you are installing. Without a specified tag, npm installs the latest tagged version. Open package.json again:

      This will show the following:

      locator/package.json

      {
        "name": "locator",
        "version": "1.0.0",
        "description": "Finds the country of origin of the incoming request",
        "main": "index.js",
        "scripts": {
          "test": "echo "Error: no test specified" && exit 1"
        },
        "keywords": [
          "ip",
          "geo",
          "country"
        ],
        "author": "Sammy sammy@your_domain (https://your_domain)",
        "license": "ISC",
        "dependencies": {
          "axios": "^0.19.0"
        },
        "devDependencies": {
          "eslint": "^6.0.0"
        }
      }
      

      eslint has been saved as a devDependencies, along with the version number you specified earlier. Exit package.json.

      Automatically Generated Files: node_modules and package-lock.json

      When you first install a package to a Node.js project, npm automatically creates the node_modules folder to store the modules needed for your project and the package-lock.json file that you examined earlier.

      Confirm these are in your working directory. In your shell, type ls and press ENTER. You will observe the following output:

      Output

      node_modules package.json package-lock.json

      The node_modules folder contains every installed dependency for your project. In most cases, you should not commit this folder into your version controlled repository. As you install more dependencies, the size of this folder will quickly grow. Furthermore, the package-lock.json file keeps a record of the exact versions installed in a more succinct way, so including node_modules is not necessary.

      While the package.json file lists dependencies that tell us the suitable versions that should be installed for the project, the package-lock.json file keeps track of all changes in package.json or node_modules and tells us the exact version of the package installed. You usually commit this to your version controlled repository instead of node_modules, as it’s a cleaner representation of all your dependencies.

      Installing from package.json

      With your package.json and package-lock.json files, you can quickly set up the same project dependencies before you start development on a new project. To demonstrate this, move up a level in your directory tree and create a new folder named cloned_locator in the same directory level as locator:

      • cd ..
      • mkdir cloned_locator

      Move into your new directory:

      Now copy the package.json and package-lock.json files from locator to cloned_locator:

      • cp ../locator/package.json ../locator/package-lock.json .

      To install the required modules for this project, type:

      npm will check for a package-lock.json file to install the modules. If no lock file is available, it would read from the package.json file to determine the installations. It is usually quicker to install from package-lock.json, since the lock file contains the exact version of modules and their dependencies, meaning npm does not have to spend time figuring out a suitable version to install.

      When deploying to production, you may want to skip the development dependencies. Recall that development dependencies are stored in the devDependencies section of package.json, and have no impact on the running of your app. When installing modules as part of the CI/CD process to deploy your application, omit the dev dependencies by running:

      The --production flag ignores the devDependencies section during installation. For now, stick with your development build.

      Before moving to the next section, return to the locator folder:

      Global Installations

      So far, you have been installing npm modules for the locator project. npm also allows you to install packages globally. This means that the package is available to your user in the wider system, like any other shell command. This ability is useful for the many Node.js modules that are CLI tools.

      For example, you may want to blog about the locator project that you’re currently working on. To do so, you can use a library like Hexo to create and manage your static website blog. Install the Hexo CLI globally like this:

      To install a package globally, you append the -g flag to the command.

      Note: If you get a permission error trying to install this package globally, your system may require super user privileges to run the command. Try again with sudo npm i hexo-cli -g.

      Test that the package was successfully installed by typing:

      You will see output similar to:

      Output

      hexo-cli: 2.0.0 os: Linux 4.15.0-64-generic linux x64 http_parser: 2.7.1 node: 10.14.0 v8: 7.6.303.29-node.16 uv: 1.31.0 zlib: 1.2.11 ares: 1.15.0 modules: 72 nghttp2: 1.39.2 openssl: 1.1.1c brotli: 1.0.7 napi: 4 llhttp: 1.1.4 icu: 64.2 unicode: 12.1 cldr: 35.1 tz: 2019a

      So far, you have learned how to install modules with npm. You can install packages to a project locally, either as a production or development dependency. You can also install packages based on pre-existing package.json or package-lock.json files, allowing you to develop with the same dependencies as your peers. Finally, you can use the -g flag to install packages globally, so you can access them regardless of whether you’re in a Node.js project or not.

      Now that you can install modules, in the next section you will practice techniques to administer your dependencies.

      Step 3 — Managing Modules

      A complete package manager can do a lot more than install modules. npm has over 20 commands relating to dependency management available. In this step, you will:

      • List modules you have installed.
      • Update modules to a more recent version.
      • Uninstall modules you no longer need.
      • Perform a security audit on your modules to find and fix security flaws.

      While these examples will be done in your locator folder, all of these commands can be run globally by appending the -g flag at the end of them, exactly like you did when installing globally.

      Listing Modules

      If you would like to know which modules are installed in a project, it would be easier to use the list or ls command instead of reading the package.json directly. To do this, enter:

      You will see output like this:

      Output

      ├─┬ axios@0.19.0 │ ├─┬ follow-redirects@1.5.10 │ │ └─┬ debug@3.1.0 │ │ └── ms@2.0.0 │ └── is-buffer@2.0.3 └─┬ eslint@6.0.0 ├─┬ @babel/code-frame@7.5.5 │ └─┬ @babel/highlight@7.5.0 │ ├── chalk@2.4.2 deduped │ ├── esutils@2.0.3 deduped │ └── js-tokens@4.0.0 ├─┬ ajv@6.10.2 │ ├── fast-deep-equal@2.0.1 │ ├── fast-json-stable-stringify@2.0.0 │ ├── json-schema-traverse@0.4.1 │ └─┬ uri-js@4.2.2 ...

      By default, ls shows the entire dependency tree—the modules your project depends on and the modules that your dependencies depend on. This can be a bit unwieldy if you want a high-level overview of what’s installed.

      To only print the modules you installed without their dependencies, enter the following in your shell:

      Your output will be:

      Output

      ├── axios@0.19.0 └── eslint@6.0.0

      The --depth option allows you to specify what level of the dependency tree you want to see. When it’s 0, you only see your top level dependencies.

      Updating Modules

      It is a good practice to keep your npm modules up to date. This improves your likelihood of getting the latest security fixes for a module. Use the outdated command to check if any modules can be updated:

      You will get output like the following:

      Output

      Package Current Wanted Latest Location eslint 6.0.0 6.7.1 6.7.1 locator

      This command first lists the Package that’s installed and the Current version. The Wanted column shows which version satisfies your version requirement in package.json. The Latest column shows the most recent version of the module that was published.

      The Location column states where in the dependency tree the package is located. The outdated command has the --depth flag like ls. By default, the depth is 0.

      It seems that you can update eslint to a more recent version. Use the update or up command like this:

      The output of the command will contain the version installed:

      Output

      npm WARN locator@1.0.0 No repository field. + eslint@6.7.1 added 7 packages from 3 contributors, removed 5 packages, updated 19 packages, moved 1 package and audited 184 packages in 5.818s found 0 vulnerabilities

      If you wanted to update all modules at once, then you would enter:

      Uninstalling Modules

      The npm uninstall command can remove modules from your projects. This means the module will no longer be installed in the node_modules folder, nor will it be seen in your package.json and package-lock.json files.

      Removing dependencies from a project is a normal activity in the software development lifecycle. A dependency may not solve the problem as advertised, or may not provide a satisfactory development experience. In these cases, it may better to uninstall the dependency and build your own module.

      Imagine that axios does not provide the development experience you would have liked for making HTTP requests. Uninstall axios with the uninstall or un command by entering:

      Your output will be similar to:

      Output

      npm WARN locator@1.0.0 No repository field. removed 5 packages and audited 176 packages in 1.488s found 0 vulnerabilities

      It doesn’t explicitly say that axios was removed. To verify that it was uninstalled, list the dependencies once again:

      Now, we only see that eslint is installed:

      Output

      └── eslint@6.7.1

      This shows that you have successfully uninstalled the axios package.

      Auditing Modules

      npm provides an audit command to highlight potential security risks in your dependencies. To see the audit in action, install an outdated version of the request module by running the following:

      When you install this outdated version of request, you’ll notice output similar to the following:

      Output

      + request@2.60.0 added 54 packages from 49 contributors and audited 243 packages in 7.26s found 6 moderate severity vulnerabilities run `npm audit fix` to fix them, or `npm audit` for details

      npm is telling you that you have vulnerabilities in your dependencies. To get more details, audit your entire project with:

      The audit command shows tables of output highlighting security flaws:

      Output

      === npm audit security report === # Run npm install request@2.88.0 to resolve 1 vulnerability ┌───────────────┬──────────────────────────────────────────────────────────────┐ │ Moderate │ Memory Exposure │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Package │ tunnel-agent │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Dependency of │ request │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Path │ request > tunnel-agent │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ More info │ https://npmjs.com/advisories/598 │ └───────────────┴──────────────────────────────────────────────────────────────┘ # Run npm update request --depth 1 to resolve 1 vulnerability ┌───────────────┬──────────────────────────────────────────────────────────────┐ │ Moderate │ Remote Memory Exposure │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Package │ request │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Dependency of │ request │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ Path │ request │ ├───────────────┼──────────────────────────────────────────────────────────────┤ │ More info │ https://npmjs.com/advisories/309 │ └───────────────┴──────────────────────────────────────────────────────────────┘ ...

      You can see the path of the vulnerability, and sometimes npm offers ways for you to fix it. You can run the update command as suggested, or you can run the fix subcommand of audit. In your shell, enter:

      You will see similar output to:

      Output

      + request@2.88.0 added 19 packages from 24 contributors, removed 32 packages and updated 12 packages in 6.223s fixed 2 of 6 vulnerabilities in 243 scanned packages 4 vulnerabilities required manual review and could not be updated

      npm was able to safely update two of the packages, decreasing your vulnerabilities by the same amount. However, you still have four vulnerabilities in your dependencies. The audit fix command does not always fix every problem. Although a version of a module may have a security vulnerability, if you update it to a version with a different API then it could break code higher up in the dependency tree.

      You can use the --force parameter to ensure the vulnerabilities are gone, like this:

      As mentioned before, this is not recommended unless you are sure that it won’t break functionality.

      Conclusion

      In this tutorial, you went through various exercises to demonstrate how Node.js modules are organized into packages, and how these packages are managed by npm. In a Node.js project, you used npm packages as dependencies by creating and maintaining a package.json file—a record of your project’s metadata, including what modules you installed. You also used the npm CLI tool to install, update, and remove modules, in addition to listing the dependency tree for your projects and checking and updating modules that are outdated.

      In the future, leveraging existing code by using modules will speed up development time, as you don’t have to repeat functionality. You will also be able to create your own npm modules, and these will in turn will be managed by others via npm commands. As for next steps, experiment with what you learned in this tutorial by installing and testing the variety of packages out there. See what the ecosystem provides to make problem solving easier. For example, you could try out TypeScript, a superset of JavaScript, or turn your website into mobile apps with Cordova. If you’d like to learn more about Node.js, see our other Node.js tutorials.



      Source link

      SMF Add modules and packages


      Even though the SMF application provides a huge variety of functionalities for your discussion board you might get to a point when you need a specific feature to be implemented on it.

      Luckily the script developers have gone the extra mile to give you the opportunity to do so.

      In this section of our SMF tutorial we will show you how to extend the functionality of the application by installing packages on it.

      Before you proceed wit the installation you will need to go to the official SMF package repository and download the module in question.

      Next you should access the administration area of the forum and navigate to Admin > Main > Package Manager > Download Packages:

      Then scroll down the page and you will see the Upload a Package section, where you should select the package you have downloaded and click Upload:

      Once the process is completed you will be displayed with a congratulatory message and you have the option to install the module:

      To proceed with the installation you just need to click on the Install Now button:

      These were all the steps you need to perform. You will be now displayed with a message stating the the installation process has been successfully completed:



      Source link