angular 2, angular-cli: Wie werden relative Pfade für den Stift aktiviert?

Question

Als Ausgangspunkt für den Anschluss unseres Winkels 1.5 Anwendung Winkel 2, habe ich eine Projektvorlage mit Winkel-cli:

ng new pd --style=styl 

Stylus Kompilierung funktioniert im Prinzip gut, aber verwendet absoluten Pfad.

Meine globale Griffel-Datei (style.styl) sieht aus wie

@require "~@mgm-a12/plasma-design/stylus/plasma.styl" 

Die "plasma.styl" ist ein Einstiegspunkt (zu unternehmensweiten Stilen) und verwendet relative Pfade, zum Beispiel (zwei „@ erfordert“tief aus plasma.styl):

background url("../assets/img/sprite.png") no-repeat 

, wenn ich zu bauen versuchen, ich diesen Fehler:

ModuleNotFoundError: Module not found: Error: Can't resolve 
'../assets/img/sprite.png' 
in '.../pd/src' 
at .../pd/node_modules/webpack/lib/Compilation.js:229:38 

(so es versucht, die URL basierend auf dem Pfad der globalen stylus.styl, die falsch ist)

Die akzeptierte Antwort hier Webpack && stylus-loader incorrectly resolve url paths sagt, um "resolve url" zu den Stift-Lader-Optionen hinzuzufügen.

Aber wo zum Teufel kann ich diese Option in den Dateien von eckigen-Cli erstellt werden?

Answer 1

Die Webpack-Loader sind im Winkel konfiguriert. Die meisten sind in /angular-cli/models/webpack-build-common.js enthalten Wenn ich Zeilen aus

in dieser Datei ändern

loaders: ['style-loader', 'css-loader', 'postcss-loader', 'stylus-loader'] 

zu

loaders: ['style-loader', 'css-loader', 'postcss-loader', 'stylus-loader?resolve url'] 

es funktioniert gut.

Natürlich ist das keine praktikable Lösung (denn für mein Projekt ist diese Konfigurationsdatei eine temporäre Datei im Ordner node_modules).

Leider Winkel cli (absichtlich) bietet keine Möglichkeit, die webpack Config anpassen: https://github.com/angular/angular-cli/issues/1656#issuecomment-239366723

Als Abhilfe, die ich Code zu meinem package.json des npm Skript hinzugefügt, dass Kopien Vermögenswerte aus dem referenzierten Stift Ordner auf meine Projekt (nur um die Importe funktionieren zu lassen). Da dies jedoch nicht das einzige Problem war, das wir mit angular-cli hatten, müssen wir bald zu einem benutzerdefinierten Webpack-Build migrieren.