Ich bin mir nicht sicher, ob dies machbar ist oder in das Node.js-Repository gehört.

Was warum

Es gibt oft Fälle, in denen bestimmte Abhängigkeiten bestimmte Build-Konfigurationen erfordern, um in einer Gesamtumgebung (zum Beispiel) ordnungsgemäß zu funktionieren.

Diese Konfiguration kann eine Babel-Konfiguration, eine Webpack-Konfiguration oder eine speziell für dieses Paket angepasste Konfiguration sein.

Derzeit gibt es keine standardisierte Möglichkeit, Pakete zu konfigurieren.

Manche Leute verwenden eine Konvention, bei der sie ein Feld in package.json das nach dem Paket benannt ist, und ein Paket kann das lesen. Aber es fühlt sich nicht Standard genug an.

Wann

Wenn ein Paket eine benutzerdefinierte Konfiguration für die Laufzeit oder Buildzeit benötigt.

Woher

Wie

Es ist manchmal der Fall, dass JavaScript für bestimmte Fälle Build-Schritte benötigt. Diese Konfigurationsfunktion hätte eine optionale Option zum Erstellen von Abhängigkeiten, die an jedes Paket übergeben werden kann (ob sie native Module erstellen oder einfach JavaScript in eine niedrigere Form transpilieren).

Abhängig von der Konfiguration benötigt ein Paket möglicherweise bestimmte Abhängigkeiten, die es sonst nicht benötigen würde (zB Build-Abhängigkeiten).

Das Paketsystem wäre also intelligent genug, da es, wenn ein Benutzer eine bestimmte Paketkonfiguration hat, bestimmen kann, welche zusätzlichen Abhängigkeiten installiert werden sollen.

Vielleicht muss diese Funktion nur vom bestehenden nativen Modulsystem auf das gesamte JavaScript-System erweitert werden (auf einfache Weise sind native Module knifflig).

Dies könnte auch für Dinge wie optionale Abhängigkeiten sehr nützlich sein. Es wäre einfach, mit config anzugeben, dass eine Bibliothek (zum Beispiel) three anstelle von babylonjs . Dies würde dazu führen, dass die entsprechende Abhängigkeit installiert wird. Es ist ähnlich wie Peer-Abhängigkeiten, aber einfacher, und ein bestimmtes Paket, das von optionalen deps abhängt, hätte eine Standardmethode, um zuverlässig auf die Konfigurations-API zuzugreifen, um zu bestimmen, ob bestimmte Bedingungen angegeben sind (dies ist derzeit schwierig, und jede Cystom-Durchquerung von node_modules ist nicht- Standard in diesen Fällen).

Aktuelles Verhalten

• n / A

Erwartetes Verhalten

• oben auf hohem Niveau abgedeckt

Als weiteres Beispiel müssen Paketkonsumenten manchmal Paketquellen anstelle der üblichen kompilierten Ausgabe verwenden, um den Code auf unterschiedliche Weise zu kompilieren (normalerweise möchte ich dies mit Webpack tun).

Generell gibt es bei solchen Dingen Probleme, für die NPM bisher keine gängige Lösung bietet.

Wer

Paketautoren und ihre Benutzer

Verweise

• n / A