Grunt watch hängt sich auf UND ab 5.3 RC (2) werden keine Grunt Tasks mehr in phpStorm gefunden

Hallo Community, 

ich habe zwei Probleme mit Grunt: 

  1. Grunt watch reagiert im laufenden Betrieb nach ein paar Speicherungen nicht mehr. Es steht einfach weiterhin “Waiting…:” da. Ein speichern wird nicht mehr registriert… einfach so?!
  2. Seitdem Grunt nun modular aufgebaut ist, findet phpStorm keine Tasks mehr. Somit muss ich über das Terminal arbeiten.

 

Versionen:

npm -v = 2.15.9
node -v = 4.6.0
grunt -v = 1.2.0

 

Hallo,

woran erkennst Du, dass sich Grunt watch aufhängt? Ich vermute eher, der läuft schon, erkennt nur keine Dateiänderungen. Jedes mal, wenn Du neue JavaScript Dateien in einem Theme anlegst, dann musst die config neu generieren lassen. Denn Grunt liest nämlich diese config ein und weiß anhand dessen, welche Dateien er watchen soll. Das hat sich auch in 5.3 RC 2 nicht geändert, jedenfalls wurde bei der Umstellung der Konsole Task nicht verändert, was darauf schließen lässt: SW-18562 Fixed - ESLint optimazations and modularized grunt · shopware/shopware@892df67 · GitHub

Probier doch also bitte mal die Datei neu zu generieren über das Kommando

php console sw:theme:dump:configuration

Zu dem Problem “phpstorm findet keine Tasks mehr”: Du musst phpstorm den Pfad zur Gruntfile.js mitteilen, wenn er sie nicht automatisch findet. Musste ich damals auch machen. Um das zu tun, navigierst Du in der Project Toolbox nach themes/Gruntfile.js und gehst mit Rechtsklick drauf -> “Show Grunt Tasks”. Genaueres dazu findest Du in der offiziellen Doku: You will be redirected shortly

 

 

MFG

 

derwunner

Hallo derwunner, 

das Dumpen der Config ist klar. Mache ich, wenn ich im Backend kompiliere usw. und eine frische config_1.json benötige. Das ist leider nicht das Problem  Blush
Allerdings besteht das Problem schon etwats länger. Vll. schon seit SW v5.2.24?!

 

Auch zum zweiten Teil deiner Hilfe ist es so, dass ich einfach rechtsklick auf die Gruntfile.js mache und dann „Show Grunt tasks“ anklicke. Hat bisher immer geklappt.

@dupp schrieb:

Hallo derwunner, 

das Dumpen der Config ist klar. Mache ich, wenn ich im Backend kompiliere usw. und eine frische config_1.json benötige. Das ist leider nicht das Problem  Blush
Allerdings besteht das Problem schon etwats länger. Vll. schon seit SW v5.2.24?!

Das kann nicht sein. Ich verwende selbst  5.2.26 täglich und es funtkioniert bei mir einwandfrei. Wie Du oben aus dem Commit entnehmen kannst, ist das ein Ticket, was für 5.3 RC 2 eingeplant war. Erst damit kam der modulare Aufbau von Grunt. Bei 5.2 ist alles noch beim alten.

 

Der Rest - keine Ahnung. Was passiert denn, wenn der watch Task läuft und Du eine Datei änderst, die sicher in der config_1.json steht. Erkennt Grunt die Änderung und kompiliert neu? Daher auch nochmal die Frage: Bist du absolut sicher, dass der watch Task hängt? Ich hatte das jedenfalls noch nie gehört. Und wenn der watch Task wirklilch hängen würde, dann hätten sich schon viele Leute viel lauter beschwert.

@derwunner schrieb:

@dupp schrieb:

Hallo derwunner, 

das Dumpen der Config ist klar. Mache ich, wenn ich im Backend kompiliere usw. und eine frische config_1.json benötige. Das ist leider nicht das Problem  Blush
Allerdings besteht das Problem schon etwats länger. Vll. schon seit SW v5.2.24?!

Das kann nicht sein. Ich verwende selbst  5.2.26 täglich und es funtkioniert bei mir einwandfrei. Wie Du oben aus dem Commit entnehmen kannst, ist das ein Ticket, was für 5.3 RC 2 eingeplant war. Erst damit kam der modulare Aufbau von Grunt. Bei 5.2 ist alles noch beim alten.

 

Ich glaub hier vermischt sich was. Ich habe mich in meiner Antwort auf den Watcher bezogen, welcher irgendwann den Geist aufgibt, obwohl ich lediglich in LESS Änderungen mache. Ich wollte auch zu keinem Zeitpunkt sagen , dass das Aufhängen des Watchers etwas mit dem modularen neuen Aufbau von Grunt ab der SW 5.3 zu tun hat. 

 

Daher nochmal:

Problem 1 bereits vor Version 5.3 - Watcher hängt sich auf

Problem 2 ab Version 5.3 - phpStorm findet Tasks nicht mehr. (Nicht mehr = es ging vorher und ich weiß was zu tun war)  Sticking-out-tongue

 

Der Rest - keine Ahnung. Was passiert denn, wenn der watch Task läuft und Du eine Datei änderst, die sicher in der config_1.json steht. Erkennt Grunt die Änderung und kompiliert neu? Daher auch nochmal die Frage: Bist du absolut sicher, dass der watch Task hängt? Ich hatte das jedenfalls noch nie gehört. Und wenn der watch Task wirklilch hängen würde, dann hätten sich schon viele Leute viel lauter beschwert.

Ich arbeite nun seit Einführung von SW 5 regelmäßig mit Grunt. Gab nie Probleme. Erst in den letzten Versionen der 5.2.x ist mir aufgefallen, dass der Watcher einfach stehen bleibt. Ich arbeite in der selben Datei. Schreiben, speichern, Änderung ansehen. Watcher läuft durch. Nach x-Speicherungen in der selben Datei passiert einfach nichts mehr. Ist mir jetzt bei den letzten drei Shopumsetzungen aufgefallen, die ich im letzten Monat gemacht habe… Man muss vll. dazu sagen, ich arbeite unter Windows lokal mit XAMPP und nicht mir Vagrant und Co.

 

 

//EDIT: Gerade wieder passiert… arbeite fleißig an der footer.less… und nun geht es wieder nicht… 

Hallo zusammen,

wir hatten diesen Fall intern auch schon einmal konnten ihm aber nicht genau reproduzieren. Könnt ihr mir ein paar Informationen zu eurer Development Umgebung geben:

  • Node.js & npm Version
  • Betriebssystem samt Dateisystem-Format

Das Problem ist vermutlich der File-Watcher “chokidar”, den wir seit 5.2 im Einsatz haben. Der Watcher wurde aufgrund eines GitHub PRs umgesetzt: Grunt: use chokidar instead of grunt-contrib-watch by screeny05 · Pull Request #521 · shopware/shopware · GitHub

Bzgl. der modularen Tasks - die Tasks werden On-Demand über das Grunt Plugin “load-config-grunt” geladen. “grunt-jit” wird dafür verwenden NPM Tasks automatisch zu laden. Ich schaue mir das Problem bzgl. PhpStorm und Grunt einmal genauer an. Das Problem ist das Grunt-Plugin von PhpStorm, welches die Tasks nicht dynamisch auslesen kann. Ich melde mich wenn ich hier weitere Informationen für euch habe.

Viele Grüße,
Stephan Pohl  Shopware

Hallo [@Stephan Pohl](http://forum.shopware.com/profile/2/Stephan Pohl “Stephan Pohl”)‍

Versionen (wie oben im Beitrag):

npm -v = 2.15.9
node -v = 4.6.0
grunt -v = 1.2.0

Windows 10 Pro Version 1703 - Dateisystem ist NTFS

PhpStorm 2017.2

 

Ich glaube das Einfrieren hängt möglicherweise auch mit phpStorm zusammen. Ich habe mal eine andere console verwendet (git bash). Da ist es bisher nicht aufgetreten. Beim Googlen habe ich auch was bezüglich der Eigenschaften der Windows Console gelesen, dass man diese auch auf “Legacy” stellen könne. Das versuche ich nun mal. 

Hey @dupp‍,

danke für deine Rückmeldung. PhpStorm / WebStorm haben eine Auto-Saving Funktion für Dateien, welche ggf. hier auch mit reinspielt. Kannst du einmal schauen wie es sich verhält, wenn du die Funktion deaktivierst.

http://www.dotmana.com/weblog/2012/07/disable-auto-save-in-phpstorm/

Viele Grüße,
Stephan Pohl  Shopware

Ok gut, ich sollte auch sagen, dass ich unter Mac OS X arbeite. Hier konnte ich jedenfalls das Problem noch nicht reproduzieren.

@dupp‍ Wie ist es denn bei Dir unter Windows? Was passiert denn, wenn Du Grunt aus einer cmd32.exe Console aufrufst? Und wie verhält sich das ganze in der PowerShell? Bei der PowerShell bitte mal beide Varianten ausprobieren, also sowohl 32 als auch 64 Bit.

Nachdem ich cmd32 auf legacy umgestellt habe, lief die Konsole gute 2 Stunden durch ohne Probleme. Jetzt hängt sie allerdings wieder. Leider kann ich keinen Anhaltspunkt finden.

Autosaving beim Fensterwechsel und nach Zeit habe ich ausgeschaltet, weil das im Zusammenhang mit LiveReload ziemlich nervt.

Ich kann ja jetzt mal mit cmd testen.

@dupp‍ Danke dass du dir die Zeit nimmst und probiert die Ursache des Problems nachzustellen. Ich bin persönlich unter Mac OS X unterwegs und kann das Problem auch nach einen vollen Arbeitstag nicht reproduzieren.

Falls wir bis morgen die Ursache nicht gefunden haben, werde ich euch ein Package mit Grunt samt grunt-contrib-watch zur Verfügung stellen. Möchte hiermit sicherstellen dass es sich um ein Problem von chokidar handelt.

Kann es ja nebenbei testen, da ich eh gerade an einer Umsetzung bin. 

Dass chokidar mal nach zwei Stunden hängt wäre noch nicht mal so schlimm. Hatte es zeitweise nur häufiger. 

Wenn es mal hängt wäre es auch kein Problem, wenn man wenigstens die Auflistung der Grunt-Tasks hätte. Dann wäre es ein klick. Da das unter 5.3 nur aktuell auch nicht geht muss man eben jedesmal ein neues Terminal öffen in themes navigieren und dann grunt starten. (jetzt auch kein Weltuntergang, aber vorher ging es ja auch)

So mittlerweile hängt nun auch CMD… allerdings geht hier ab dem Schritt Running „less:development“ (less) task nichts mehr… habe lange gewartet… 

 

@dupp schrieb:

So mittlerweile hängt nun auch CMD… allerdings geht hier ab dem Schritt Running „less:development“ (less) task nichts mehr… habe lange gewartet… 

 

Wenn das öfters an dieser Stelle hängt, dann würde ich Dich mal bitten den Log und Verbose Modus von Grunt an zu machen, damit man nachvollziehen kann, woran das liegt.

Und jetzt weiß ich endlich was Du mit cmd legacy Modus meinst, Du hast scheinbar Windows 10. Ich gurke privat noch auf maximal Windows 8 rum, aus gutem Grund: Mag sein, dass Windows 10 mittlerweile nur noch 10 Euro die Lizenz kostet, würde ich auch sofort nehmen, aber es ist mir noch zu gesprächig nach Redmond, dank der neuen Sprachtechnik, die auch Anfragen an den Microsoft Server stellt, wenn sie eigentlich komplett ausgeschaltet ist. Manche Datenschützer gehen sogar so weit und behaupten, dass man Windows 10 gar nicht im Unternehmen einsetzen kann, weil das Mitarbeiter Spionage wäre.

Auch wenn ich nichts zu verbergen habe, geht es Microsoft dennoch nichts an, was ich wann auf meinen PC tue, welche Programme ich gerade verwende, welche Sprache ich eingestellt habe, etc…

Auch mit grunt --verbose wird nichts weiter angezeigt. Es registriert einfach meine Datei-Speicherungen nicht mehr…