10 Antworten zu „Entwicklungsumgebung für Gutenberg-Blöcke einrichten“

1. 

   florian

   10. Januar 2019

   Im Dezember 2020 hat Flo eine neue Version dieses Artikel hier im KrautPress-Blog geschrieben.

   Um einen Gutenberg-Block zu entwickeln, braucht es theoretisch nichts außer einem Text-Editor. Wer sich das Leben aber etwas leichter machen möchte (oder mindestens zunächst schwerer, wenn die Tools noch nicht bekannt sind), kann

   Babel einsetzen, um mit modernem JavaScript zu entwickeln, das nach Kompilierung trotzdem auch von älteren Browsern verstanden wirdSASS einsetzen, um sich Schreibarbeit bei den Styles zu sparen undein Tool wie Webpack nutzen, um Babel und die SASS-Kompilierung (und eventuelle weitere Dinge, wie automatische Generierung eines SVG-Sprites aus vielen einzelnen SVG-Icons, et cetera) nicht immer manuell anstoßen zu müssen.

   Hier zeige ich am Beispiel von Webpack ein minimales Setup, das modernes JavaScript mit Babel kompiliert und SASS zu CSS macht.

   Update vom 1. Juni 2019: Der Beitrag zeigt jetzt die Nutzung des NPM-Pakets @wordpress/scripts, was die Einrichtung von Webpack und Babel deutlich erleichtert.

   Voraussetzungen

   Ich gehe davon aus, dass ihr

   eine lokale WordPress-Installation laufen undNode sowie NPM (kommt in der Regel mit der Node-Installation mit) installiert habt.

   Außerdem könnt ihr innerhalb des wp-content/plugins-Ordners schon mal ein leeres Verzeichnis für das Plugin anlegen (oder zum Verzeichnis eines existierenden Plugins wechseln), für das ihr später Webpack nutzen wollt.

   package.json erstellen und Abhängigkeiten installieren

   Begebt euch über die Kommandozeile in das gerade erstellte Plugin-Verzeichnis und führt den Befehl npm init aus. Jetzt solltet ihr einige Dinge zum Ausfüllen bekommen und am Ende bestätigen können, dass eine package.json mit dem angezeigten Inhalt erstellt werden soll.

   Nachdem ihr eine package.json vorliegen habt, müssen wir uns ans Installieren der Abhängigkeiten machen. Überlegen wir kurz, was wir brauchen:

   WebpackBabelSASS-Kompilierer

   Webpack und Babel installieren

   Bis vor Kurzem mussten wir uns noch um die Installation der ganzen Abhängigkeiten selbst kümmern. Inzwischen bringt das NPM-Paket @wordpress/scripts alle Tools für einen grundlegenden Babel-Workflow via Webpack mit. Im Beitrag »Building JavaScript« auf make.wordpress.org gibt es nähere Details dazu.

   Alles, was wir für die Installation von Webpack und Babel machen müssen, ist also:

   .wp-block-code {
   border: 0;
   padding: 0;
   }

   .wp-block-code > div {
   overflow: auto;
   }

   .shcb-language {
   border: 0;
   clip: rect(1px, 1px, 1px, 1px);
   -webkit-clip-path: inset(50%);
   clip-path: inset(50%);
   height: 1px;
   margin: -1px;
   overflow: hidden;
   padding: 0;
   position: absolute;
   width: 1px;
   word-wrap: normal;
   word-break: normal;
   }

   .hljs {
   box-sizing: border-box;
   }

   .hljs.shcb-code-table {
   display: table;
   width: 100%;
   }

   .hljs.shcb-code-table > .shcb-loc {
   color: inherit;
   display: table-row;
   width: 100%;
   }

   .hljs.shcb-code-table .shcb-loc > span {
   display: table-cell;
   }

   .wp-block-code code.hljs:not(.shcb-wrap-lines) {
   white-space: pre;
   }

   .wp-block-code code.hljs.shcb-wrap-lines {
   white-space: pre-wrap;
   }

   .hljs.shcb-line-numbers {
   border-spacing: 0;
   counter-reset: line;
   }

   .hljs.shcb-line-numbers > .shcb-loc {
   counter-increment: line;
   }

   .hljs.shcb-line-numbers .shcb-loc > span {
   padding-left: 0.75em;
   }

   .hljs.shcb-line-numbers .shcb-loc::before {
   border-right: 1px solid #ddd;
   content: counter(line);
   display: table-cell;
   padding: 0 0.75em;
   text-align: right;
   -webkit-user-select: none;
   -moz-user-select: none;
   -ms-user-select: none;
   user-select: none;
   white-space: nowrap;
   width: 1%;
   }
   npm install --save-dev @wordpress/scripts
Code-Sprache: Bash (bash)

   SASS installieren

   Kommen wir zum SASS-Teil. Wir brauchen zunächst verschiedene Loader, um das SASS über Webpack zu verarbeiten und als eigene Datei auszugeben. Mit PostCSS wollen wir automatisch den Autoprefixer über das Ergebnis laufen lassen.

   npm install --save-dev css-loader extract-loader file-loader postcss-loader sass-loader
Code-Sprache: Bash (bash)

   Jetzt kommen noch die Abhängigkeiten node-sass, autoprefixer und postcss-cli:

   npm install --save-dev autoprefixer postcss-cli node-sassCode-Sprache: Bash (bash)

   Konfigurationsdateien erstellen

   Nachdem wir jetzt alle Abhängigkeiten installiert haben, machen wir uns an das Erstellen zweier Konfigurationsdateien. Eine für PostCSS und eine für Webpack, die die Standard-Konfiguration erweitert, die mit @wordpress/scripts geliefert wird. Die beiden Dateien kommen auf dieselbe Ebene wie die package.json.

   PostCSS konfigurieren

   Die postcss.config.js sieht so aus:

   module.exports = {
plugins: {
autoprefixer: { grid: true }
}
}
Code-Sprache: JavaScript (javascript)

   Wir möchten den Autoprefixer nutzen und auch alte CSS-Grid-Syntax nachrüsten. Die Liste der unterstützten Browser geben wir über die package.json an:

   "browserslist": [
"extends @wordpress/browserslist-config"
],
Code-Sprache: JSON / JSON mit Kommentaren (json)

   Damit werden dieselben Browser berücksichtigt, die offiziell von WordPress unterstützt werden. Über npx autoprefixer --info könnt ihr euch anzeigen lassen, welche Browser das sind und welche Eigenschaften und Werte betroffen sind.

   Damit das funktioniert, müssen wir dieses NPM-Paket noch installieren:

   npm install --save-dev @wordpress/browserslist-config
Code-Sprache: Bash (bash)

   Webpack konfigurieren

   Wenn man mit Webpack nur JavaScript kompilieren möchte und nur eine Datei hätte, bräuchte man keine eigene Konfiguration zu erstellen. @wordpress/scripts bringt bereits eine mit, die eine src/index.js zu einer build/index.js kompiliert.

   Das reicht uns allerdings nicht, deshalb erstellen wir für Webpack eine webpack.config.js-Datei und füllen sie mit dem folgenden Inhalt, um die Standard-Konfiguration zu erweitern (diese Basis-Webpack-Konfiguration findet ihr im GitHub-Repo des @wordpress/scripts-Pakets):

   const defaultConfig = require("./node_modules/@wordpress/scripts/config/webpack.config");
const path = require('path');
module.exports = {
...defaultConfig,
entry: ['./blocks/index.js', './blocks/editor.scss', './blocks/frontend.scss'],
output: {
path: path.resolve(__dirname, 'assets'),
filename: 'js/editor.blocks.js',
},
module: {
rules: [
/**
* Running Babel on JS files.
*/
...defaultConfig.module.rules,
{
test: /.scss$/,
use: [
{
loader: 'file-loader',
options: {
name: 'css/[name].blocks.css',
}
},
{
loader: 'extract-loader'
},
{
loader: 'css-loader?-url'
},
{
loader: 'postcss-loader'
},
{
loader: 'sass-loader'
}
]
}
]
}
};
Code-Sprache: JavaScript (javascript)

   Gehen wir die Datei der Reihe nach durch:

   In defaultConfig speichern wir die Konfigurationsdatei des @wordpress/scripts-Pakets, auf die wir aufbauen wollen.In path speichern wir uns das Node-Modul path, um später den Pfad zum Ausgabeverzeichnis der Dateien anzugeben.Innerhalb von module.exports leben die konkreten Angaben zur Konfiguration von Webpack.Über ...defaultConfig kippen wir erst mal die Werte der Standard-Konfiguration rein. Es folgen die Punkte, die wir im Vergleich zum Standard anpassen wollen.Mit entry geben wir als Array die Quelldateien an (die könnt ihr in dem Zuge direkt einmal erstellen). Wir haben im blocks-Verzeichnis eine JavaScript-Datei sowie zwei SASS-Dateien.Über output legen wir fest, dass der Ausgabepfad assets sein soll und die JavaScript-Datei innerhalb von assets in ein Unterverzeichnis js mit dem Namen editor.blocks.js abgespeichert wird.In module legen wir die Regeln fest, die für die entry-Dateien angewandt werden sollen.Wir beginnen mit den Regeln der Standard-Konfiguration, die wir über ...defaultConfig.module.rules einfügen. Damit ist die Kompilierung der JavaScript-Datei bereits erledigt.Für alle .scss-Dateien sollen mehrere Loader ausgeführt werden, die letztlich das SASS in CSS kompilieren und das Ergebnis nach dem Schema [name].blocks.css innerhalb des css-Verzeichnisses ablegen. Wir haben also dann zwei CSS-Dateien assets/css/editor.blocks.css und assets/css/frontend.blocks.css als Ergebnis. Ich bin nicht ganz sicher, warum zum Beispiel der extract-loader notwendig ist, aber ohne funktioniert es nicht 🙂

   Einfach und intuitiv ist die Webpack-Konfiguration nicht wirklich, aber wenn man sich erst mal ein funktionierendes Grund-Setup zusammengesucht hat, kann man es ja in neuen Projekten wiederverwenden und bei Bedarf erweitern/anpassen.

   NPM-Skripte für den Einsatz von Webpack erstellen

   Für den Aufruf von Webpack erstellen wir jetzt noch zwei NPM-Skripte und schreiben dafür folgendes in die package.json, wie es im Beitrag zu dem @wordpress/scripts-Package beschrieben ist:

   "scripts": {
"start": "wp-scripts start",
"build": "wp-scripts build"
}
Code-Sprache: JSON / JSON mit Kommentaren (json)

   Über npm run start können wir Webpack für die Entwicklung ausführen lassen, wobei dann auch gleich auf Änderungen an den Dateien gewartet wird. Mit npm run build kompilieren wir die Dateien für den Live-Betrieb. Eventuell werdet ihr beim ersten mal aufgefordert, ein Webpack-CLI zu wählen, das dann global installiert wird.

   Jetzt können wir mit den Dateien blocks/index.js, blocks/editor.scss und blocks/frontend.scss arbeiten und bekommen durch den Aufruf von Webpack Ausgabedateien in assets, die das Plugin einbinden kann.

   Im nächsten Artikel werden wir um die Konfiguration ein kleines funktionierendes Plugin erstellen.

   Antworten
2. 

   Florian Brinkmann

   17. Dezember 2020

   Sehr viel einfacher, auch wenn die Länge des Artikels es nicht vermuten lässt (es ist sehr viel optionales dabei) 🙂
   

   Antworten
3. 

   Florian Brinkmann

   17. Dezember 2020

   Dieser Article wurde erwähnt auf brid-gy.appspot.com

   Antworten
4. 

   Jonathan Schneider 🔥

   17. Dezember 2020

   Dieser Article wurde erwähnt auf brid-gy.appspot.com

   Antworten
5. 

   Florian Brinkmann

   17. Dezember 2020

   Dieser Article wurde erwähnt auf brid-gy.appspot.com

   Antworten
6. 

   r 23

   17. Dezember 2020

   Im Januar 2019 hat @flobrinkmann zuletzt über das Einrichten einer Gutenberg-Entwicklungsumgebung geschrieben. 🤯

   Heute schaut er sich das G

   Antworten
7. 

   r 23

   17. Dezember 2020

   Im Januar 2019 hat @flobrinkmann zuletzt über das Einrichten einer Gutenberg-Entwicklungsumgebung geschrieben. 🤯

   Heute schaut er sich das Ganze nochmal an. Spoiler: es ist einfacher geworden. 🥳

   krautpress.de/2020/gutenberg…

   Antworten
8. 

   r 23

   17. Dezember 2020

   Dieser Article wurde erwähnt auf brid-gy.appspot.com

   Antworten
9. 

   Johannes Kinast

   17. Dezember 2020

   Dieser Article wurde erwähnt auf brid-gy.appspot.com

   Antworten
10. 

    Florian Brinkmann

    27. Februar 2023

    Dieser Article wurde erwähnt auf brid.gy

    Antworten

Mentions

• 💬 Florian Brinkmann
• 💬 Johannes Kinast
• 💬 r 23
• 💬 r 23
• 💬 r 23
• 💬 Florian Brinkmann
• 💬 Jonathan Schneider 🔥
• 💬 Florian Brinkmann
• 💬 Florian Brinkmann
• 💬 florian