@villedemontreal/general-utils 5.15.6 → 5.16.2

package/README.md

@@ -1,21 +1,17 @@
-# @villemontreal/core-utils-general-nodejs-lib
+# @villedemontreal/general-utils
 
 Ensemble d'utilitaires généraux.
 
 Fournie également des constantes globales, par exemple les noms d'environnements
 standardisés pour nos projets.
 
-## Availabililty
-
-https://bitbucket.org/villemontreal/core-utils-general-nodejs-lib
-
 ## Installation
 
 Install it:
 
 ```shell
-    npm install @villemontreal/core-utils-general-nodejs-lib
-    yarn add @villemontreal/core-utils-general-nodejs-lib
+    npm install @villedemontreal/general-utils
+    yarn add @villedemontreal/general-utils
 ```
 
 ## Usage
@@ -23,7 +19,7 @@ Install it:
 Exemple :
 
 ```typescript
-import { utils } from '@villemontreal/core-utils-general-nodejs-lib';
+import { utils } from '@villedemontreal/general-utils';
 ```
 
 # Builder le projet
@@ -64,10 +60,10 @@ Trois "_launch configurations_" sont founies pour déboguer le projet dans VSCod
 - "`Debug current tests file - fast`". Lance le fichier de tests _présentement ouvert_ dans VSCode en mode debug. Aucune compilation
   n'est effectuée au préalable. Cette launch configuration doit être utilisée lorsque la compilation incrémentale roule (voir la section "`Mode Watch`" plus haut)
 
-# Notes sur la dépendance "@villemontreal/core-utils-scripting-core-nodejs-lib"
+# Notes sur la dépendance "@villedemontreal/scripting"
 
 Pour éviter d'avoir une hiérarchie trop profonde dans `node_modules`, nous incluons la librarie de scripting
-"`@villemontreal/core-utils-scripting-core-nodejs-lib`" en spécifiant uniquement _sa version majeure_
+"`@villedemontreal/scripting`" en spécifiant uniquement _sa version majeure_
 (par exemple: "`^1`" ou "`^2`"). La raison est que cette librairie de scripting, ainsi que la librairie présente,
 s'utilisent chacune mutuellement. En spécifiant uniquement la version majeure de la librairie
 de scripting, seul _le plus récent artifact_ à cette version majeure sera ajouté ici au `node_modules`.
@@ -76,44 +72,6 @@ de scripting, seul _le plus récent artifact_ à cette version majeure sera ajou
 de ne pas provoquer de dépendances circulaires en important des composants de la librairie de scripting qui eux-mêmes importeraient en ce faisant des composants de la librairie présente! D'hériter de la classe `ScriptBase` serait,
 cela dit, sans problème car cet import ne génère aucune dépendance circulaire.
 
-# Test et publication de la librairie sur Nexus
-
-En mergant une pull request dans la branche `develop`, un artifact "`-pre.build`" sera créé automatiquement dans Nexus. Vous
-pouvez utiliser cette version temporaire de la librairie pour bien la tester dans un réel projet.
-
-Une fois mergée dans `master`, la librairie est définitiement publiée dans Nexus, en utilisant la version spécifiée dans
-le `package.json`.
-
-## Artifact Nexus privé, lors du développement
-
-Lors du développement d'une nouvelle fonctionnalité, sur une branche `feature`, il peut parfois être
-utile de déployer une version temporaire de la librairie dans Nexus. Ceci permet de bien tester
-l'utilisation de la librairie modifiée dans un vrai projet, ou même dans une autre librairie
-elle-même par la suite utilisée dans un vrai projet.
-
-Si le code à tester est terminé et prêt à être mis en commun avec d'autres développeurs, la solution
-de base, comme spécifiée à la section précédante, est de merger sur `develop`: ceci créera
-automatiquement un artifact "`-pre-build`" dans Nexus. Cependant, si le code est encore en développement
-et vous désirez éviter de polluer la branche commune `develop` avec du code temporaire, il y a une
-solution permettant de générer un artifact "`[votre prénom]-pre-build`" temporaire dans Nexus,
-à partir d'une branche `feature` directement:
-
-1. Checkoutez votre branche `feature` dans une branche nommée "`nexus`". Ce nom est
-   important et correspond à une entrée dans le `Jenkinsfile`.
-2. Une fois sur la branche `nexus`, ajoutez un suffixe "`-[votre prénom]`" à
-   la version dans le `package.json`, par exemple: "`5.15.0-roger`".
-   Ceci permet d'éviter tout conflit dans Nexus et exprime clairement qu'il
-   s'agit d'une version temporaire pour votre développement privé.
-3. Commitez et poussez la branche `nexus`.
-4. Une fois le build Jenkins terminé, un artifact pour votre version aura été
-   déployé dans Nexus.
-
-**Notez** que, lors du développement dans une branche `feature`, l'utilisation d'un simple
-`npm link` local peut souvent être suffisant! Mais cette solution a ses limites, par exemple si
-vous désirez tester la librairie modifiée _dans un container Docker_.
-
 # Aide / Contributions
 
-Pour obtenir de l'aide avec ce gabarit, vous pouvez poster sur la salle Google Chat [dev-discussions](https://chat.google.com/room/AAAASmiQveI).
-
 Notez que les contributions sous forme de pull requests sont bienvenues.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@villedemontreal/general-utils",
-  "version": "5.15.6",
+  "version": "5.16.2",
   "description": "General utilities library",
   "main": "dist/src/index.js",
   "typings": "dist/src",
@@ -38,17 +38,15 @@
   "license": "MIT",
   "dependencies": {
     "@types/app-root-path": "1.2.4",
-    "@types/lodash": "4.14.156",
+    "@types/lodash": "4.14.171",
     "@types/luxon": "1.25.0",
-    "@types/marked": "1.1.0",
     "@types/rimraf": "3.0.0",
     "app-root-path": "3.0.0",
     "get-port": "5.1.1",
     "globby": "11.0.1",
-    "http-status-codes": "1.4.0",
+    "http-status-codes": "2.1.4",
     "lodash": "4.17.21",
     "luxon": "1.25.0",
-    "marked": "1.1.0",
     "moment": "2.27.0",
     "rimraf": "3.0.2",
     "tsconfig-extends": "1.0.1"