web-dev-qa-db-fra.com

Quelle est la bonne façon d'utiliser un paquet npm dépendant dans un projet de bibliothèque angular 6?

Je suis un peu confus quant à la façon dont je suis supposé faire référence à des paquets npm externes dans mon projet de bibliothèque angular6. Nous avons une bibliothèque scss interne que j'aimerais utiliser pour styliser mes composants réutilisables dans ma bibliothèque. Comment puis-je importer cela?

package.json pour le projet lib:

{
  "name": "ikr-lib",
  "version": "0.0.1",
  "peerDependencies": {
    "@angular/common": "^6.0.0-rc.0 || ^6.0.0",
    "@angular/core": "^6.0.0-rc.0 || ^6.0.0",
    "document-register-element": "1.8.1"
  },
  "dependencies": {
    "element.ui": "^1.0.1"
  }
}

Quand je construis le projet de bibliothèque, je reçois ceci:

Distributing npm packages with 'dependencies' is not recommended. Please consider adding element.ui to 'peerDependencies' or remove it from 'dependencies'.

BUILD ERROR
Dependency element.ui must be explicitly whitelisted.
angular6angular-library
7
cobolstinks

Il semble que l'ajout du nom du paquet à une collection "whitelistedNonPeerDependencies" dans le fichier ng-package.json résoudra ce problème de construction. Je ne sais toujours pas quelle est la meilleure pratique ici. Devrions-nous créer des bibliothèques angulaires qui ont des dépendances sur d’autres packages npm ou est-il préférable d’avoir que peerDependancies? 

fichier ng-package.json:

{
  "$schema": "../../node_modules/ng-packagr/ng-package.schema.json",
  "dest": "../../dist/ikr-lib",
  "deleteDestPath": false,
  "lib": {
    "entryFile": "src/public_api.ts"
  },
  "whitelistedNonPeerDependencies": [
    "element.ui"
  ]
}
3
cobolstinks

C’est plus une conjecture que une réponse officielle, mais voici ce que j’ai compris de ce que j’ai trouvé et pensé jusqu’à présent. 

Le code source donne un indice sur leur raisonnement :

// Vérifie les dépendances non-peer car elles peuvent facilement mener à des installations en double ou à des conflits de version dans le dossier node_modules d'une application.

Je pense donc qu'ils s'inquiètent d'un scénario dans lequel la bibliothèque elle-même dépend d'une version, alors que l'application utilisant cette bibliothèque peut utiliser une autre version. 

Utiliser ^ dans la version est la configuration par défaut pour l'installation de dépendances. De même, utiliser ^ dans le numéro de version dédupliquera les dépendances qui diffèrent par les versions mineures ou les correctifs. Donc, je pense que la principale préoccupation concernerait la version majeure.

Quelques exemples du point de vue du node_modules de l'application:

  • App: ^2.8.3, bibliothèque: ^2.8.0 => dédupliqué (2.8.3)
  • App: ^2.9.0, bibliothèque: ^2.3.4 => dédupliqué (2.9.0)
  • App: ^3.0.1, Bibliothèque: ^2.3.4 => dupliquer (3.0.1 et 2.3.4 existent)

Cela pourrait gonfler la taille de l'application ou provoquer un conflit quant à la version que les outils tenteront de charger en tant que dépendance.

Cette réponse parle aussi un peu de pourquoi utiliser plutôt peerDependencies.

1
Doug Swain