Bootstrap entfernen für Custom-Theme Entwicklung

Hallo zusammen,

für die lokale Theme- und Plugin-Entwicklung verwende ich das Production Template. Der Watcher (bin/watch-storefront.sh) für Storefront-Changes, funktioniert mit dem Proxie-Aufruf http://localhost:9998 problemlos. Mein Custom-Theme, würde ich gerne mit eigenem Plain-CSS enwtickeln und Bootstrap durch die Storefront Vererbung ausschließen. HIerfür habe ich in meinem Cutsom-Theme in der theme.json den Eintrag “@Storefront” unter “style” entfernt. Unter http://localhost werden nun die Styles des Storefont-Theme nicht mehr übernommen, aber wenn ich den Watcher starte und die Seite unter http://localhost:9998 aufrufe, werden die Styles des Storefront-Theme weiterhin intergriert.

Hat jemand eine Idee woran das liegen könnte?

 

Viele Grüße
Michael

Nachtrag …

Zum Test habe ich im Storefront-Theme, in der theme.json den “style” Eintrag entfernt:

“style”: [
    {
      “app/storefront/src/scss/base.scss”: {
        “resolve”: {
          “vendor”: “app/storefront/vendor”
        }
      },
      “app/storefront/src/scss/skin/shopware/_base.scss”: {
        “resolve”: {
          “vendor”: “app/storefront/vendor”
        }
      }
    },

Trotzdem wird nach dem Build (bin/build-js.sh) im Watcher (bin/watch-storefront.sh > http://localhost:9998), noch der komplette Bootstrap CSS angezeigt.

Woher holt sich der Watcher die Daten um mit der addStyles.js auszuspielen?

Viele Grüße
Michael

Ich vermute, du musst die Storefront mit 

./psh.phar storefront:build

rebuilden. Der watcher compiliert deine scss Änderungen live, verlässt du den watcher musst du ab und zu mal wieder die storefront rebuilden, dass webpack wieder alle scss und js files verarbeitet und komprimiert.

LG Luca

Hallo @lucahollenbach‍ ,

vielen Dank für deine Antwort.

Leider bringt ein “bin/console theme:refresh” & “bin/build-storefront.sh” nichts. Das komplette CSS des Storefront-Themes wird weiterhin angzeigt.

Hat vielleicht noch jemand eine andere Idee, woran das liegen könnte?

Beste Grüße
Michael

Hallo [@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski „Moritz Naczenski“)‍,

ich habe zu meinem Post ein konkrete Frage an dich…

Kann es sein, das der Watcher im Production-Template die theme.json ignoriert und einfach nur das komplett SCSS lädt?

 

Beste Grüße
Michael

Keine Ahnung, kann ich dir leider nicht beantworten. Ich schau mal ob es ein Kollege weiss.

1 „Gefällt mir“

Hi @dbb ich hab mich auch damit beschäftigt (siehe: Best practices für wirklich individuelle Shops/Themes "from scratch")

Das Problem ist, dass der Watch Task komplett über nodeJS/Webpack läuft, sowohl JS als auch SCSS. Beim Build Task z.B. bei storefront:build wird nur das JS von Webpack kompiliert. Das SCSS wird über PHP kompiliert mit phpscss. So kann Shopware auch über das Admin immer ein aktuelles CSS Bundle generieren, in dem nur relevantes CSS von aktiven Themes und Plugins enthalten ist. JS muss wie gesagt in einer Umgebung mit nodeJS und dem Build Task kompiliert werden. Dabei wird ein Bundle erzeugt, das dem Theme/Plugin dann beiliegt und von Shopware ebenfalls je nach aktiv/inaktiv injected werden kann.

Wenn du also kontrollieren willst, was bei storefront:hot-proxy oder auch bei storefront:build als Entrypoint genutzt wird, musst du die Webpack Konfiguration überschreiben.

Dazu musst du unter /ExamplePlugin/src/Resources/app/storefront/build/ die Datei webpack.config.js anlegen. So könnte der Inhalt für ein Theme, dass nur JS und SCSS von sich selbst zulässt aussehen:

const path = require('path');
const isHotMode = process.env.MODE === 'hot';

// provide extendable object for building (storefront entrypoints are not inherited by theme.json)
let entry = {};

// force override with function for hot reloading (storefront entrypoints are removed)
if (isHotMode) {
    entry = () => {
        return {
            storefront: [
                path.resolve(__dirname, '../src/main.js'),
                path.resolve(__dirname, '../../../../../../../../var/theme-entry.scss')
            ]
        }
    }
}

module.exports = () => {
    return {
        entry: entry,
        optimization: {
            runtimeChunk: false,
            splitChunks: false
        }
    };
}

Für den Build Task wird ein JS Objekt genutzt, das von Shopware Skripten erweitert und gemerged werden kann, da wir die Dependencies hier über die theme.json konfigurieren können.

Für den Watch Task überschreibt man die Entrypoints mit einer Funktion. Die kann von den Skripten dann nicht mehr erweitert werden, wirft auch zum Glück soweit keine Fehler.

In der optimization muss noch festgelegt werden, das keine Junks erzeugt werden. Das hat natürlich den Nachteil, dass man das Code splitting für das komplette Frontend deaktiviert und das alle Skripte nun beim initialen Laden der Seite geladen werden. Also evtl. keine gute Idee für den Community Store.

Das alles habe ich allerdings in einer shopware/development Umgebung gemacht, wie sich das bei den Production Skripten verhält, kann ich dir leider nicht sagen. Bin sehr offen für Verbesserungsvorschläge!

PS: Hast du dir schon mal Shopware PWA angeschaut? GitHub - vuestorefront/shopware-pwa: Shopware PWA for eCommerce. Headless storefront solution for Shopware 6, which communicates through the SalesChannel-API. Always Open Source, MIT license. Made with by shopware AG & Vue Storefront. Evtl. der bessere Ansatz für ein ganz eigenes Frontend, bin auch am überlegen.