theme watcher lauscht nicht

Ich habe gerade einmal über die cli ein neues theme angelegt, theme aktiviert - und den watcher gestartet mit ./psh.phar storefront:watch

Der kompiliert zwar den ersten kram, lauscht aber auf nichts. Wenn ich nun die base.scss des generierten Themes anpasse passiert gar nichts. Ebenso der hot-reload, selbe Problem. Der watcher scheint auf nichts zu lauschen, bemerkt keine Änderungen - nichts.

/storefront/main.js funktioniert. Aber partout nicht die .scss files in /storefront/styles/main.scss

Ich stehe gerade etwas auf dem Trichter … mach ich hier iwas falsch? :slight_smile:

Aktuellste git Version, npm 6.5, node v11

Ich habe jetzt in den Docs gelesen, dass die sass files vom theme über den php-compiler kompiliert werden.

Heißt das, dass die theme sass files daher gar nicht mit dem watcher funktionieren? Gibt es hier keinen watch task für die sass files von themes?

Ich stehe total aufn Schlauch …  Gasp

Hi Shopwareianer,

grundsätzlich hast du erstmal nichts falsch gemacht. Der SCSS watch bzw. hot Modus funktioniert zurzeit leider nicht mit Plugins. Wir arbeiten im Moment daran, das Ganze wieder lauffähig zu machen. Keine Sorge, auch wenn die SCSS Dateien serverseitig kompiliert werden (für die Theme Konfiguration in der Administration), soll der watch Modus für Development trotzdem funktionieren. Hierzu wird es ein theme:dump Command geben, um die SCSS Variablen für die lokale Entwicklung zur Verfügung zu stellen.

Es wird voraussichtlich diese Woche ein Patch-Release geben, in der auch der theme:dump Command enthalten ist. Bis dahin kann der theme:compile Command verwendet werden, um die SCSS Dateien zu kompilieren.

Viele Grüße
Tobias Berge

1 „Gefällt mir“

[@Tobias Berge](http://forum.shopware.com/profile/20591/Tobias Berge “Tobias Berge”)‍ Alles klar, gut zu wissen, danke :slight_smile:

[@Tobias Berge](http://forum.shopware.com/profile/20591/Tobias Berge “Tobias Berge”)‍ Gibt es zum Thema HMR für Plugins bereits Neuigkeiten?

 

In EA 1.1 scheint es auch noch nicht enthalten zu sein :frowning:

In EA 1.1 scheint es Anpassungen im Theme- & Hot-Reload-Code gegeben zu haben, aber trotzdem bringe ich weder storefront:hot noch storefront:watch für custom Plugins zum laufen. Mach ich da was falsch? Müsste das mittlerweile funktionieren?

Hallo zusammen,

ich habe den storefront:hot Command gerade nochmal getestet auf dem EA 1.1 Stand mit einem Theme Plugin. Bei mir funktioniert es für CSS und JavaScript Änderungen im Plugin. Habt ihr die Variable  {% set isHMRMode = true %} gesetzt in der src/Storefront/Resources/views/base.html.twig?

Zeigt euch der storefront:hot Befehl Fehler in der Konsole an? Falls ja, könntet ihr diese posten? Dann schauen wir uns das genauer an.

Viele Grüße
Tobias

[@Tobias Berge](http://forum.shopware.com/profile/20591/Tobias Berge “Tobias Berge”)‍ Vielen Dank für die Antwort. Ich habe das ganze Szenario gerade nochmals durchgespielt - ohne Erfolg.

Setup:

git clone git@github.com:shopware/development.git
cd development
git clone git@github.com:shopware/platform.git
bin/setup

(http://sw-clean:8888 im Browser testen: Funktioniert, sieht alles gut aus!)

bin/console theme:create
bin/console plugin:refresh
bin/console plugin:install --activate Test
./psh.phar cache
bin/console theme:refresh
bin/console theme:change
	Sales Channel: [0] Storefront
	Theme: [1] Test

platform/src/Storefront/Resources/vies/base.html.twig anpassen:
	Zeile 2: {% set isHMRMode = true %}

./psh.phar storefront:hot

Fehlermeldungen gibts da keine, aber beim Starten vom Hot-Reload wird folgende Warnung angezeigt:

WARNING: We noticed you're using the `useBuiltIns` option without declaring a core-js version. Currently, we assume version 2.x when no version is passed. Since this default version will likely change in future versions of Babel, we recommend explicitly setting the core-js version you are using via the `corejs` option.

	You should also be sure that the version you pass to the `corejs` option matches the version specified in your `package.json`'s `dependencies` section. If it doesn't, you need to run one of the following commands:

	  npm install --save core-js@2 npm install --save core-js@3
	  yarn add core-js@2 yarn add core-js@3

Wenn ich die Seite dann im Browser aktualisere, wird keinerlei CSS geladen (im Quelltext ist kein einziges “.css” vorhanden und der einzige style-Tag ist von der Symfony-Toolbar).

Interessanterweise scheint webpack sogar auf Anpassungen im base.scss-File meines Plugins zu hören: Wenn ich da etwas anpasse, wird in der Shell folgendes ausgegeben:

ℹ Compiling Shopware 6 Storefront
✔ Shopware 6 Storefront: Compiled successfully in 41.65ms
DONE Compiled successfully in 548ms9:51:55 PM

 

 

Beim JavaScript siehts etwas anders aus; folgende Script-Tags sind im Quelltext:

So können die Files natürlich nicht geladen werden. Scheinbar läuft da mit

 app.request.server.get('REQUEST\_SCHEME')

Auf Zeile 140 im base.html.twig etwas schief. Wenn ich da stattdessen “http” hardcode, stimmen zwar die URLs:

Aber einige der Files werden trotzdem nicht geladen da die gar nicht existieren (storefront.js und app.js).

Der Content vom Hot-Reload-Server scheint ja von platform/src/Storefront/Resources/dist aus geserved zu werden, so sieht die Struktur des Folders bei mir aus:

tree platform/src/Storefront/Resources/dist
platform/src/Storefront/Resources/dist
├── assets
│   ├── defaultThemePreview.jpg
│   ├── font
│   │   ├── ...
│   ├── icon
│   │   ├── default
│   │   │   ├── ...
│   │   └── solid
│   │   ├── ...
│   └── logo
│   ├── android-touch-icon.png
│   ├── apple-touch-icon.png
│   ├── demostore-logo.png
│   └── favicon.png
├── js
│   ├── runtime.js
│   ├── vendor-node.js
│   └── vendor-shared.js
└── storefront
    └── js
        └── storefront.js

9 directories, 380 files

Wenn ich Zeile 146 im base.html.twig anpasse zu:

Kann diese Datei geladen werden, dann fehlt also nur noch die app.js - und natürlich das ganze CSS, aber wenn ich das richtig verstanden habe müsste das dann per JavaScript geladen werden.

Änderungen am all.js File des Plugins triggern bei mir übrigens  keine Reaktion in der hot-reload Shell.

Anscheinend lag das Problem an den Port-Nummern (siehe Shopware Issuetracker)

Pull-Request ist erstellt: NEXT-3849 - Fix hostname in hot reload URL by Alex--C · Pull Request #162 · shopware/platform · GitHub

@alexc schrieb:

Anscheinend lag das Problem an den Port-Nummern (siehe https://issues.shopware.com/issues/NEXT-3849)

Pull-Request ist erstellt: https://github.com/shopware/platform/pull/162

Das brauchst du gar nicht. Die Variabel ist einfach nur falsch gesetzt: https://github.com/shopware/storefront/blob/master/Resources/views/base.html.twig#L140

Es darf nicht ‚://‘ heißen, sondern ‚//‘, dann funktioniert es auch. 

Hier der PR => https://github.com/shopware/platform/pull/171

@Shopwareianer schrieb:

@alexc schrieb:

Anscheinend lag das Problem an den Port-Nummern (siehe https://issues.shopware.com/issues/NEXT-3849)

Pull-Request ist erstellt: https://github.com/shopware/platform/pull/162

Das brauchst du gar nicht. Die Variabel ist einfach nur falsch gesetzt: https://github.com/shopware/storefront/blob/master/Resources/views/base.html.twig#L140

Es darf nicht ‚://‘ heißen, sondern ‚//‘, dann funktioniert es auch. 

Hier der PR => https://github.com/shopware/platform/pull/171

Das reichte in meinem Fall nicht (siehe mein Beitrag weiter oben, da hab ich alles genau beschrieben). Mit der falschen Portnummer hat der Dev-Server nur die Files aus der Ordnerstruktur geserved, und da fehlt bspw. die app.js.

@alexc‍ Aber warum denn falsche Portnummer? :9999 ist doch alles korrekt. Es ging ja nur darum, dass ein falscher Pfad ausgegeben worden ist 

://

Das ist ja nicht korrekt, da es // sein muss.

Probier mal meinen fix - Das hat den Fehler bei mir behoben. Nun funktioniert hot-reload ohne Probleme, da die files alle korrekt geladen werden mit dem richtigen Pfad.

@Shopwareianer‍ Port :9999 wäre schon korrekt, aber da meine APP_URL bereits einen Port enthält (bspw. http://localhost:8888) wurde der publicPath des Dev-Servers auf “http://localhost:8888:9999” gesetzt.

Aus irgendeinem Grund (kenne Webpack zu wenig um zu wissen warum) wurden so dann nur die Files aus dem “platform/src/Storefront/Resources/dist”-Ordner geserved, einige Files (app.js) fehlten aber - die werden wohl irgendwie von Webpack gecached und direkt aus dem Memory geladen?

Sobald ich den publicPath des devServers korrigiere (zu “http://localhost:9999”, siehe mein Pull-Request) funktioniert alles (natürlich musste ich die base.html.twig trotzdem noch korrigieren, wie von dir beschrieben).