Je ne sais pas si cela est faisable ou si cela appartient au référentiel Node.js.

Quoi / Pourquoi

Il existe souvent des cas où certaines dépendances nécessitent des configurations de build spécifiques pour fonctionner correctement dans un environnement global (par exemple).

Cette configuration peut être une configuration Babel, une configuration Webpack ou quelque chose de personnalisé juste pour ce package.

Dans l'état actuel des choses, il n'existe aucun moyen normalisé de configurer les packages.

Certaines personnes utilisent une convention où elles placent un champ dans package.json nommé d'après le package, et un package peut le lire. Mais cela ne semble pas assez standard.

Lorsque

Lorsqu'un package a besoin d'une configuration personnalisée pour l'exécution ou le temps de construction.

Où

Comment

Il arrive parfois que JavaScript ait besoin d'étapes de construction pour certains cas. Cette fonctionnalité de configuration aurait une option facultative « construire les dépendances » qui peut être transmise à n'importe quel package (qu'ils construisent des modules natifs ou transpilent simplement JavaScript vers une forme inférieure).

Selon la configuration, un paquet peut avoir besoin de certaines dépendances dont il n'aurait pas besoin autrement (par exemple des dépendances de construction).

Ainsi, le système de packages serait suffisamment intelligent, en ce sens que si un utilisateur a une certaine configuration de package, il peut déterminer les dépendances supplémentaires à installer.

Peut-être que cette fonctionnalité doit simplement être étendue du système de module natif existant au système JavaScript global (d'une manière facile à utiliser, les modules natifs sont délicats).

Cela pourrait également être très utile pour des choses comme les dépendances facultatives. Il serait facile, avec config, de spécifier qu'une bibliothèque utilise (par exemple) three au lieu de babylonjs . Cela entraînerait l'installation de la dépendance appropriée. C'est similaire aux dépendances entre pairs, mais plus facile, et un package donné qui dépend de deps facultatifs aurait un moyen standard d'accéder à l'API de configuration de manière fiable pour déterminer si certaines conditions sont spécifiées (c'est actuellement délicat, et toute traversée de cystom de node_modules est non- standard dans ces cas).

Comportement actuel

• n / A

Comportement prévisible

• couvert ci-dessus à un niveau élevé

Autre exemple, parfois les consommateurs de packages ont besoin de consommer la source du package au lieu de la sortie compilée habituelle afin de compiler le code de différentes manières (généralement pour moi, j'ai envie de le faire avec Webpack).

En général, il y a des problèmes avec ce genre de choses, que NPM ne fournit jusqu'à présent aucun moyen commun de gérer.

Qui

auteurs de packages et leurs utilisateurs

Les références

• n / A