Bedingte Schluck-Concat für mehrere Aufgaben

8

Ich habe eine Schlucktask namens build, die Teilaufgaben verwendet, um verschiedene Teile meiner Quelle in einen Build-Ordner zu verschieben:

%Vor%

Ich wollte dann einige zusätzliche Schritte hinzufügen, wenn --env = prod, was ich mit gulp-if gemacht habe:

%Vor%

Das funktioniert gut. Das letzte, was ich tun möchte, ist, alle js-Dateien aus diesen Teilaufgaben zu schlucken. Ich gehe davon aus, dass ich gulpif verwenden kann, um einen Stream von jeder Aufgabe zurückzugeben, anstatt nach gulp.dest zu gehen, aber ich müsste trotzdem eine Aufgabe ausführen, um diese Ströme zu kombinieren und concat.

Gibt es einen besseren Weg, dies zu tun?

    
Dan 06.02.2014, 15:24
quelle

2 Antworten

14
___ tag123gulp ___ Gulp ist ein JavaScript-Build-System, ein Node.js-basierter Task-Runner wie Grunt. Gulp verwendet Streams und Code-over-Konfiguration für einen einfacheren und intuitiveren Build-Prozess. ___ qstnhdr ___ Bedingte Schluck-Concat für mehrere Aufgaben ___ qstntxt ___

Ich habe eine Schlucktask namens build, die Teilaufgaben verwendet, um verschiedene Teile meiner Quelle in einen Build-Ordner zu verschieben:

%Vor%

Ich wollte dann einige zusätzliche Schritte hinzufügen, wenn --env = prod, was ich mit gulp-if gemacht habe:

%Vor%

Das funktioniert gut. Das letzte, was ich tun möchte, ist, alle js-Dateien aus diesen Teilaufgaben zu schlucken. Ich gehe davon aus, dass ich gulpif verwenden kann, um einen Stream von jeder Aufgabe zurückzugeben, anstatt nach gulp.dest zu gehen, aber ich müsste trotzdem eine Aufgabe ausführen, um diese Ströme zu kombinieren und concat.

Gibt es einen besseren Weg, dies zu tun?

    
___ answer23430363 ___

Achten Sie darauf, Ihre Aufgaben in so viele kleinere Module wie möglich aufzuteilen und sich dann an das DRY-Prinzip zu halten, wo Sie können.

In Ihrem Fall. Zum Beispiel haben Sie vielleicht eine Standardaufgabe compile , die Sie zum Laufen bringt und vielleicht einige build-prod Aufgaben und generische %code% Aufgaben während der Entwicklung ausführt. Wenn Sie Ihren Code für ein Release bereitstellen möchten, haben Sie möglicherweise eine Art von Konfigurationsoptionen, die definiert, welche Dateien für die Veröffentlichung freigegeben werden sollen. Zusammen mit diesem haben Sie vielleicht eine %code% Aufgabe, die über die Konfigurationsdatei schaut und dann alle benötigten Quellen, Prozesse, Konkats, Higgles usw. sammelt und dann an ein spezifiziertes Build-Ziel ausgibt.

Randnotiz: Es ist viel einfacher, jetzt mit der neuesten Version von %code% an das DRY-Prinzip zu kommen, da Sie jetzt Arrays als Callback-Funktion übergeben können.

Ich habe einige gulpfiles, die ich mehr als glücklich mit Ihnen teilen würde, wenn Sie eine Hand brauchen.

    
___ answer21600002 ___

Anstatt alles in eine Build-Aufgabe zu stecken, warum sollte man nicht eine separate Aufgabe für %code% oder %code% haben. Dies würde Ihren Code viel einfacher zu pflegen und weniger anfällig machen.

Sie können immer noch Teile von Aufgaben wiederverwenden, indem Sie diese in Funktionen einkapseln:

%Vor%

Oder, wenn Sie Teile wiederverwendbaren Codes haben, können Sie lazypipe verwenden, um diese zu erstellen und nach Bedarf zu verwenden:

%Vor%

Ich denke auch, dass es eine schlechte Idee ist, Ihre Produktions- und Entwicklungs-Builds an denselben Standort zu bringen. Sie werden den dev build zufällig an einem bestimmten Punkt installieren.

Ich habe eine ziemlich große gulfile, die das tut , wenn das hilft zu sehen, was ich meine, aber es klingt wie Du hast schon eine Menge Arbeit in deinem.

    
___
OverZealous 06.02.2014, 16:07
quelle
0

Achten Sie darauf, Ihre Aufgaben in so viele kleinere Module wie möglich aufzuteilen und sich dann an das DRY-Prinzip zu halten, wo Sie können.

In Ihrem Fall. Zum Beispiel haben Sie vielleicht eine Standardaufgabe dev , die Sie zum Laufen bringt und vielleicht einige watch Aufgaben und generische build Aufgaben während der Entwicklung ausführt. Wenn Sie Ihren Code für ein Release bereitstellen möchten, haben Sie möglicherweise eine Art von Konfigurationsoptionen, die definiert, welche Dateien für die Veröffentlichung freigegeben werden sollen. Zusammen mit diesem haben Sie vielleicht eine release Aufgabe, die über die Konfigurationsdatei schaut und dann alle benötigten Quellen, Prozesse, Konkats, Higgles usw. sammelt und dann an ein spezifiziertes Build-Ziel ausgibt.

Randnotiz: Es ist viel einfacher, jetzt mit der neuesten Version von gulp-watch an das DRY-Prinzip zu kommen, da Sie jetzt Arrays als Callback-Funktion übergeben können.

Ich habe einige gulpfiles, die ich mehr als glücklich mit Ihnen teilen würde, wenn Sie eine Hand brauchen.

    
jh3y 02.05.2014 14:20
quelle

Tags und Links