Web­pack für ein Word­Press-Pro­jekt nutzen

Inhalt

Web­pack ist ursprüng­lich als Paket­ma­na­ger für Pro­jek­te in Java­script geschaf­fen wor­den und ver­wal­tet auch „Zube­hör” wie css- und Type­script-Files, ein­ge­bet­te­te Bil­der oder die die Rück­über­set­zung in älte­re ECMA-Ver­sio­nen mit Babel. Aber ist es auch für ein Word­Press-Pro­jekt nutzbar?

Ach­tung! Der Arti­kel ist noch in Arbeit!

Das Pro­blem

Die nati­ve Word­Press-Unter­stüt­zung für Java­script ist schon etwas in die Jah­re gekom­men. Für den gele­gent­li­chen Ein­satz klei­ner Skrip­te ohne vie­le Abhän­gig­kei­ten mögen wp_enqueue_script und wp_enqueue_style, ihre regis­ter-Schwes­tern und die Über­ga­be von Daten mit­tels wp_localize_script ausreichen.

Schwie­rig wird es, wenn man mit umfang­rei­chen Scripts und vie­len Abhän­gig­kei­ten arbei­tet. Da geht oft nicht nur die Über­sicht dar­über ver­lo­ren, wel­che Biblio­the­ken in wel­cher Ver­si­on zu wel­chem Zeit­punkt im Pro­jekt gela­den wer­den müs­sen. Auch die Grö­ße und Anzahl der nach­zu­la­den­den Datei­en nimmt stän­dig zu, was die Web­sei­te nicht gera­de schnel­ler macht.

Für rei­ne Java­script-Pro­jek­te gibt es für sol­che Pro­ble­me Abhil­fe. Der Packa­ge-Mana­ger npm von node.js sorgt dafür, dass die nöti­gen Biblio­the­ken vor­han­den und aktu­ell sind. Modul-Packer wie Web­pack stel­len Anwen­dungs­pa­ke­te zusam­men, die nur genau die Scripts und Libra­ri­es ent­hal­ten, die wirk­lich nötig sind. Zudem küm­mern sie sich auch um css, Images, Kom­pri­mie­rung und vie­le wei­te­re Din­ge, die dem Pro­gram­mie­rer das Leben leich­ter machen.

Aber wie kann man die Vor­tei­le von node.js und web­pack in einem typi­schen Word­Press-Pro­jekt nut­zen, wo neben dem Cli­ent-sei­ti­gen Java­script auf der Ser­ver-Sei­te Unman­gen von PHP-Scripts werkeln?

Genau das soll die­ser Arti­kel klä­ren. Zunächst küm­mern wir uns um die Grund­la­gen, näm­lich die Instal­la­ti­on der Plattform.

Instal­la­ti­on von node.js und npm

Grund­vor­aus­set­zung für Web­pack ist ein funk­tio­nie­ren­des node.js und npm. Falls dies nicht ohne­hin schon für das Pro­jekt instal­liert war, holen wir das jetzt nach.

Für Debi­an gibt es ein fer­ti­ges Paket, das sowohl node.js als auch npm ent­hält. Ein Set­up-Script von node­sour­ce trägt die Paket­quel­le ein:

$ sudo curl -sL https://deb.nodesource.com/setup_12.x | sudo -E bash -

Danach kann das Paket instal­liert werden:

$ sudo apt install nodejs

Nach erfolg­rei­cher Instal­la­ti­on soll­te node.js und npm sei­ne jewei­li­ge Ver­si­on aus­ge­ben können:

$ node --version
v12.13.0
$ npm --version
6.13.1

Web­pack installieren

Die Instal­la­ti­on von Web­pack über­nimmt der node packa­ge mana­ger npm:

$ npm install --save-dev webpack webpack-cli webpack-merge

So instal­liert wird web­pack als Ent­wick­lungs-Abhän­gig­keit in die package.json-Datei des loka­len Pro­jekts ein­ge­tra­gen. Das Kom­man­do­zei­len-Paket web­pack-cli muss seit Ver­si­on 4 sepa­rat instal­liert wer­den. Das web­pack-mer­ge-Modul brau­chen wir spä­ter, um meh­re­re Kon­fi­gu­ra­tio­nen mit­ein­an­der kom­bi­nie­ren zu können.

Ver­zeich­nis­struk­tur erstellen

Zunächst erzeu­gen wir in der Ent­wick­lungs­um­ge­bung ein build-Ver­zeich­nis, in das spä­ter alle nur zur Erzeu­gung des Pro­jekt­da­tei­en nöti­gen Tei­le gespei­chert wer­den. So bleibt das eigent­li­che Pro­jekt­ver­zeich­nis „sau­ber”. In die­sem Ver­zeich­nis wer­den die nöti­gen Kon­fi­gu­ra­ti­ons­da­tei­en für Ent­wick­lung und Pro­duk­ti­on angelegt:

$ mkdir build

Web­pack-Kon­fi­gu­ra­ti­on

Die Web­pack-Kon­fi­gu­ra­ti­on wird in einen gemein­sa­men und je einen Teil für Ent­wick­lung und Pro­duk­ti­on auf­ge­spal­ten. Die gemein­sa­me Kon­fi­gu­ra­ti­on erzeu­gen wir in build/config.base.js:

module.exports = {
  // gemeinsame webpack Konfiguration
}

Die Pro­duk­ti­ons-Kon­fi­gu­ra­ti­on wird in build/config.production.js eingetragen:

const merge = require('webpack-merge')

module.exports = merge(require('./config.base.js'), {
  mode: 'production'

  // webpack Konfiguration für die Produktions-Umgebung
})

Schließ­lich erzeu­gen wir build/config.development.js für die Entwicklungs-Umgebung:

const merge = require('webpack-merge')

module.exports = merge(require('./config.base.js'), {
  mode: 'development',
  watch: true

  // webpack Konfiguration für die Entwicklungs-Umgebung
})

Die eigent­li­chen Kon­fi­gu­ra­ti­ons­an­wei­sun­gen fügen wir spä­ter hinzu.

Die Ent­wick­lungs- und Pro­duk­ti­ons-Kon­fi­gu­ra­ti­on lädt jeweils die gemein­sa­me Kon­fi­gu­ra­ti­on config.base.js und fügt ihre spe­zi­el­len Defi­ni­tio­nen hin­zu. Die jewei­li­ge Kon­fi­gu­ra­ti­ons­da­tei teilt man web­pack mit dem --con­fig Schal­ter mit, z.B.

npx webpack --config build/config.development.js

Zur Arbeits­er­leich­te­rung kann man sich Abkür­zun­gen für die­se Kom­man­dos in package.json definieren:

...
{
  "scripts": {
    "dev": "webpack --config build/config.development.js",
    "prod": "webpack --config build/config.production.js"
  }
}
...

Damit ruft man Web­pack mit der jewei­li­gen Kon­fi­gu­ra­ti­on ein­fach mit npm run build bzw. npm run dev auf.

Pfa­de definieren

Eben­falls zur Arbeits­er­leich­te­rung kann man in build/paths.js Pfa­de defi­nie­ren, die dann in ande­ren Kon­fi­gu­ra­tio­nen genutzt wer­den können:

const path = require('path')

module.exports = {
  // Pfad zu den Quelldateien, insbesondere index.js
  SRC: path.resolve(__dirname, '..', 'public'),

  // Der Pfad zu den Anwendungspaketen
  DIST: path.resolve(__dirname, '..', 'public', 'dist'),

  // öffentlicher Pfad
  ASSETS: '/dist'
}

Einen Ein­stiegs­punkt definieren

In der gemein­sa­men Kon­fi­gu­ra­ti­ons­da­tei build/config.base.js defi­nie­ren wir den Ein­stiegs­punkt der Appli­ka­ti­on als ent­ry point im exports-Block. Das ist das Script, das wir spä­ter im PHP des Word­Press-Ser­vers per wp_enqueue_script einbinden.

const path = require('path')
const { SRC, DIST, ASSETS } = require('./paths')

module.exports = {
  entry: {
    scripts: path.resolve(SRC, 'js', 'index.js')
  },
  output: {
    // Das dist-Verzeichnis enthält die Anwendungespakete
    path: DIST,

    // Der Startpunkt heißt "scripts.js"
    filename: '[name].js',

    // Die URL zum Aufruf des Anwendungspakets
    publicPath: ASSETS
  }
}

Gibt es meh­re­re sol­cher ein­ge­bun­de­ner Scripts, müs­sen auch meh­re­re Ein­stiegs­punk­te defi­niert wer­den. Sämt­li­che Abhän­gig­kei­ten die­ser Scripts, die ansons­ten Stück für Stück im PHP des Word­Press gela­den wer­den müss­ten, ste­cken aber schon im jewei­li­gen Anwen­dungs­pa­ket, so dass wir uns dar­um nicht mehr küm­mern müssen.

Die initia­le Javascript-Datei

Das „Haupt­pro­gramm” js/index.js impor­tiert die nöti­gen node.js-Modu­le, zum Beispiel:

import './jquery.min.js'
import './jquery.migrate.js'
import './bootstrap.js'

Das Kom­man­do npm run prod erzeugt dann in DIST eine Datei script.js, die im html des Pro­jekts mit einem <script> Tag ein­ge­bun­den wird. Sie küm­mert sich um alle ein­ge­bun­de­nen Importe.


Quel­len:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

fünf − 5 =