Weil ich darauf keine Lust mehr hatte, erledigt das bei mir jetzt ein Bash-Script, das:

• die DNS-Zone bei Cloudflare findet
• den DKIM-Key automatisch aus der Mailcow-API zieht
• alle relevanten DNS-Records für Mailcow setzt bzw. aktualisiert

In diesem Beitrag zeige ich dir:

• welche DNS-Records angelegt werden und warum
• wie das Script aufgebaut ist
• wie du die .env-Datei für deine Secrets nutzt
• wie du das Ganze in der Praxis einsetzt

Am Ende findest du das komplette Script und die passende .env-Datei als kopierbare Code-Blöcke.

Was das Script macht – einmal in Kurzform

Für eine Domain wie example.org macht das Script:

• MX: zeigt auf deinen Mailcow-Host (z. B. mail.example.org)
• SPF (TXT): Standardmäßig v=spf1 mx -all
• DKIM (TXT): Holt den Key aus der Mailcow-API und legt dkim._domainkey.example.org (oder deinen Selector) an
• DMARC (TXT): einfacher Default v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.org
• Autoconfig/Autodiscover (CNAME): autoconfig.example.org und autodiscover.example.org → mail.example.org
• MTA-STS (CNAME + TXT): mta-sts.example.org + _mta-sts.example.org
• TLS-Reporting (TXT): _smtp._tls.example.org für TLS-Reports

Wichtig: Existierende DKIM-Records mit anderen Selektoren (z. B. vom alten Mailserver) bleiben absichtlich unberührt. Solange du noch über den alten Server versendest oder alte Mails nachsigniert werden, ist das hilfreich. Aufräumen kannst du später manuell, wenn der alte Server wirklich komplett raus ist.

Voraussetzungen

Damit das Script sauber läuft, brauchst du:

• macOS oder Linux mit:
• bash
• curl
• jq
• Cloudflare-API-Token mit:
  • Zone → DNS → Edit
  • Zone → Zone → Read
• Mailcow-API-Key mit Leserechten für DKIM (/api/v1/get/dkim/{domain})
• Eine Mailcow-Instanz, z. B. https://mailcow.example.org
• Deine Domains müssen bereits als Zonen bei Cloudflare existieren

Wie das Script funktioniert

1. .env-Datei laden

Das Script liest – falls vorhanden – eine .env im selben Verzeichnis.
Darin stehen die sensitiven Daten wie API-Tokens und URLs. So bleiben die Werte getrennt vom Script selbst.

# .env automatisch laden, falls vorhanden
if [ -f .env ]; then
  echo "Lade .env..."
  set -o allexport
  source .env
  set +o allexport
fi

Die Kombination aus set -o allexport und source .env sorgt dafür, dass jede Variable aus der .env automatisch als Umgebungsvariable exportiert wird, ohne dass du überall export schreiben musst.

2. API-Variablen & Standardwerte

Das Script nutzt:

• Cloudflare API Token (CF_API_TOKEN)
• Mailcow API Key (MAILCOW_API_KEY)
• Mailcow Base-URL (MAILCOW_BASEURL)
• Mail-Host / MX-Ziel (MAIL_HOST)

Dazu kommen ein paar Default-Policies:

CF_API_TOKEN="${CF_API_TOKEN:-}"
CF_API_BASE="https://api.cloudflare.com/client/v4"

MAILCOW_BASEURL="${MAILCOW_BASEURL:-https://mail.net73.de}"
MAILCOW_API_KEY="${MAILCOW_API_KEY:-}"

DOMAIN="${1:-}"                      # Domain als CLI-Argument
MAIL_HOST="${MAIL_HOST:-mail.net73.de}"

SPF_VALUE="${SPF_VALUE:-v=spf1 mx -all}"
DMARC_VALUE="${DMARC_VALUE:-v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@${DOMAIN}}"
MTA_STS_ID="${MTA_STS_ID:-$(date +%Y%m%d)}"

TTL=3600

Ein paar Punkte dazu:

• DOMAIN kommt als erstes Argument, z. B. ./setup_mail_dns.sh example.org
• SPF_VALUE, DMARC_VALUE, MTA_STS_ID kannst du bei Bedarf über die .env überschreiben
• MTA_STS_ID nutzt einfach das aktuelle Datum als ID – reicht völlig

3. Fehler-Handling & Pflicht-Variablen

Damit du nicht mit halbgaren Umgebungen arbeitest, prüft das Script die nötigsten Variablen:

err() { echo "ERROR: $*" >&2; exit 1; }

require_env() {
  local name="$1"
  [ -n "${!name:-}" ] || err "Umgebungsvariable $name ist nicht gesetzt."
}

[ -n "$DOMAIN" ] || err "Usage: $0 <domain.tld> (z.B. example.org)"

require_env CF_API_TOKEN
require_env MAILCOW_API_KEY
require_env MAILCOW_BASEURL

Wenn z. B. CF_API_TOKEN fehlt, bricht das Script mit einer sauberen Fehlermeldung ab.

4. Cloudflare-Zone finden

Cloudflare arbeitet intern mit Zone-IDs. Die holt sich das Script über die API:

echo "Suche Cloudflare Zone-ID für ${DOMAIN}..."
ZONE_ID=$(
  curl -s -X GET "${CF_API_BASE}/zones?name=${DOMAIN}" \
       -H "Authorization: Bearer ${CF_API_TOKEN}" \
       -H "Content-Type: application/json" \
    | jq -r '.result[0].id // empty'
)

[ -n "$ZONE_ID" ] || err "Konnte Zone-ID für ${DOMAIN} nicht finden. Stimmt die Domain in Cloudflare?"

Damit bist du unabhängig von irgendwelchen manuellen IDs.

5. DKIM-Key aus der Mailcow-API ziehen

Statt den DKIM-Key per Copy & Paste ins DNS zu kippen, zieht das Script den aktuellen Key direkt aus Mailcow:

echo "Hole DKIM-Key von Mailcow für ${DOMAIN}..."

DKIM_JSON=$(
  curl -s -X GET "${MAILCOW_BASEURL}/api/v1/get/dkim/${DOMAIN}" \
       -H "X-API-Key: ${MAILCOW_API_KEY}"
)

DKIM_SELECTOR=$(echo "$DKIM_JSON" | jq -r '.dkim_selector // "dkim"')
DKIM_TXT=$(echo "$DKIM_JSON" | jq -r '.dkim_txt // empty')

[ -n "$DKIM_TXT" ] || err "Kein DKIM-TXT von Mailcow erhalten. Prüfe API-Key, Domain oder ob ein DKIM-Key angelegt wurde."

DKIM_NAME="${DKIM_SELECTOR}._domainkey.${DOMAIN}"

echo "DKIM-Selector: ${DKIM_SELECTOR}"
echo "DKIM-Record:   ${DKIM_NAME}"

• dkim_selector: z. B. dkim
• dkim_txt: der komplette DKIM-Record, wie er ins DNS gehört (inkl. v=DKIM1; k=rsa; p=…)

Das Script macht daraus später einen TXT-Record bei Cloudflare.

6. DNS-Record-Handling mit cf_upsert_record

Der eigentliche Trick steckt in einer kleinen Hilfsfunktion, die Records entweder aktualisiert oder neu anlegt:

cf_upsert_record() {
  local TYPE="$1"   # A, CNAME, MX, TXT, ...
  local NAME="$2"
  local CONTENT="$3"
  local TTL_VAL="$4"
  local PROXIED="${5:-false}"   # true/false (nur für A/AAAA/CNAME)
  local PRIORITY="${6:-0}"      # nur für MX relevant

  local DATA
  if [[ "$TYPE" == "MX" ]]; then
    DATA=$(jq -n --arg type "$TYPE" --arg name "$NAME" --arg content "$CONTENT" \
               --argjson ttl "$TTL_VAL" --argjson priority "$PRIORITY" \
               '{type:$type,name:$name,content:$content,ttl:$ttl,priority:$priority}')
  elif [[ "$TYPE" == "TXT" ]]; then
    DATA=$(jq -n --arg type "$TYPE" --arg name "$NAME" --arg content "$CONTENT" \
               --argjson ttl "$TTL_VAL" \
               '{type:$type,name:$name,content:$content,ttl:$ttl}')
  else
    DATA=$(jq -n --arg type "$TYPE" --arg name "$NAME" --arg content "$CONTENT" \
               --argjson ttl "$TTL_VAL" --argjson proxied "$PROXIED" \
               '{type:$type,name:$name,content:$content,ttl:$ttl,proxied:$proxied}')
  fi

  local EXISTING_ID
  EXISTING_ID=$(
    curl -s -X GET "${CF_API_BASE}/zones/${ZONE_ID}/dns_records?type=${TYPE}&name=${NAME}" \
         -H "Authorization: Bearer ${CF_API_TOKEN}" \
         -H "Content-Type: application/json" \
      | jq -r '.result[0].id // empty'
  )

  if [[ -n "$EXISTING_ID" ]]; then
    curl -s -X PUT "${CF_API_BASE}/zones/${ZONE_ID}/dns_records/${EXISTING_ID}" \
         -H "Authorization: Bearer ${CF_API_TOKEN}" \
         -H "Content-Type: application/json" \
         --data "${DATA}" >/dev/null
    echo "Updated ${TYPE} ${NAME}"
  else
    curl -s -X POST "${CF_API_BASE}/zones/${ZONE_ID}/dns_records" \
         -H "Authorization: Bearer ${CF_API_TOKEN}" \
         -H "Content-Type: application/json" \
         --data "${DATA}" >/dev/null
    echo "Created ${TYPE} ${NAME}"
  fi
}

Damit musst du dich im Hauptteil des Scripts nicht mehr darum kümmern, ob ein Record schon existiert.

7. Welche DNS-Records das Script setzt

Im letzten Block legt das Script alle relevanten Records für die Domain an bzw. aktualisiert sie:

echo "Lege Standard-Mailcow-DNS-Einträge für ${DOMAIN} an / aktualisiere sie..."

# MX
cf_upsert_record "MX" "${DOMAIN}" "${MAIL_HOST}" "${TTL}" "false" 10

# SPF
cf_upsert_record "TXT" "${DOMAIN}" "${SPF_VALUE}" "${TTL}"

# DKIM
cf_upsert_record "TXT" "${DKIM_NAME}" "${DKIM_TXT}" "${TTL}"

# DMARC
cf_upsert_record "TXT" "_dmarc.${DOMAIN}" "${DMARC_VALUE}" "${TTL}"

# Autoconfig / Autodiscover
cf_upsert_record "CNAME" "autoconfig.${DOMAIN}" "${MAIL_HOST}" "${TTL}" "false"
cf_upsert_record "CNAME" "autodiscover.${DOMAIN}" "${MAIL_HOST}" "${TTL}" "false"

# Optional: MTA-STS & TLS-RPT
cf_upsert_record "CNAME" "mta-sts.${DOMAIN}" "${MAIL_HOST}" "${TTL}" "false"
cf_upsert_record "TXT" "_mta-sts.${DOMAIN}" "v=STSv1; id=${MTA_STS_ID}" "${TTL}"
cf_upsert_record "TXT" "_smtp._tls.${DOMAIN}" "v=TLSRPTv1; rua=mailto:tls-reports@${DOMAIN}" "${TTL}"

echo "Fertig. Bitte DNS-Änderungen und Mailcow-Check-Tools (z.B. Mailcow DNS-Check, mail-tester.com) prüfen."

Kurz dazu:

• MX: zeigt auf deinen Mailcow-Host, Proxy ist ausgeschaltet (Cloudflare darf kein SMTP sprechen)
• SPF: minimalistisch, erlaubt nur den MX-Server
• DKIM: nutzt den aktuellen Key aus Mailcow
• DMARC: schickt Reports an dmarc-reports@deine-domain
• Autoconfig/Autodiscover: hilft Mail-Clients bei der Auto-Konfiguration
• MTA-STS & TLSRPT: härten Transportverschlüsselung und sammeln TLS-Reports

8. Was ist mit alten DKIM-Records?

Viele migrieren von einem alten Mailserver (anderer Provider, eigene Kiste, …) zu Mailcow. Oft existieren dort bereits DKIM-Records mit einem anderen Selector, z. B.:

• google._domainkey.example.org
• mailjet._domainkey.example.org
• oldserver1._domainkey.example.org

Das Script fasst diese bewusst nicht an.

Das ist kein Bug, sondern Feature: Solange der alte Mailserver noch Mails mit seinem Key signiert (oder alte Nachrichten Relevanz haben), ist es sinnvoll, die alten DKIM-Keys im DNS zu lassen. Erst wenn du sicher bist, dass der alte Server endgültig außer Betrieb ist, kannst du seine Selektoren gezielt löschen – das ist eine Entscheidung, die ich lieber manuell treffen möchte.

Praxis: Setup, .env und Aufruf

1. Script speichern

Speichere das Script z. B. als setup_mail_dns.sh in ein Verzeichnis deiner Wahl.

2. .env anlegen

Im selben Verzeichnis legst du eine Datei .env an, z. B.:

export CF_API_TOKEN="xxxxxxx"
export MAILCOW_API_KEY="xxxxxxx"
export MAILCOW_BASEURL="https://mailcow.example.org"
export MAIL_HOST="mail.example.org"

Für weitere Domains kannst du MAIL_HOST gleich lassen, wenn alle denselben Mailcow-Host nutzen.

3. Script ausführbar machen und aufrufen

chmod +x setup_mail_dns.sh
./setup_mail_dns.sh example.org

Für jede weitere Domain:

./setup_mail_dns.sh andere-domain.tld

Komplettes Script (kopierfertig)

#!/usr/bin/env bash
# .env automatisch laden, falls vorhanden
if [ -f .env ]; then
  echo "Lade .env..."
  set -o allexport
  source .env
  set +o allexport
fi

set -euo pipefail

# 1) Cloudflare
CF_API_TOKEN="${CF_API_TOKEN:-}"    # besser als Umgebungsvariable setzen
CF_API_BASE="https://api.cloudflare.com/client/v4"

# 2) Mailcow
MAILCOW_BASEURL="${MAILCOW_BASEURL:-https://mail.net73.de}"  # ohne trailing slash
MAILCOW_API_KEY="${MAILCOW_API_KEY:-}"

# 3) Domain & Mailserver
DOMAIN="${1:-}"           # z.B. example.org (als Argument)
MAIL_HOST="${MAIL_HOST:-mail.net73.de}"  # MX-Ziel

# 4) Mail-Policy Defaults
SPF_VALUE="${SPF_VALUE:-v=spf1 mx -all}"
DMARC_VALUE="${DMARC_VALUE:-v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@${DOMAIN}}"
MTA_STS_ID="${MTA_STS_ID:-$(date +%Y%m%d)}"  # z.B. 20251115

TTL=3600

# ============================
# HILFSFUNKTIONEN
# ============================

err() { echo "ERROR: $*" >&2; exit 1; }

require_env() {
  local name="$1"
  [ -n "${!name:-}" ] || err "Umgebungsvariable $name ist nicht gesetzt."
}

# Upsert-Funktion für DNS-Records
cf_upsert_record() {
  local TYPE="$1"   # A, CNAME, MX, TXT, ...
  local NAME="$2"
  local CONTENT="$3"
  local TTL_VAL="$4"
  local PROXIED="${5:-false}"   # true/false (nur für A/AAAA/CNAME)
  local PRIORITY="${6:-0}"      # nur für MX relevant

  # JSON-Body je nach Typ bauen
  local DATA
  if [[ "$TYPE" == "MX" ]]; then
    DATA=$(jq -n --arg type "$TYPE" --arg name "$NAME" --arg content "$CONTENT" \
               --argjson ttl "$TTL_VAL" --argjson priority "$PRIORITY" \
               '{type:$type,name:$name,content:$content,ttl:$ttl,priority:$priority}')
  elif [[ "$TYPE" == "TXT" ]]; then
    DATA=$(jq -n --arg type "$TYPE" --arg name "$NAME" --arg content "$CONTENT" \
               --argjson ttl "$TTL_VAL" \
               '{type:$type,name:$name,content:$content,ttl:$ttl}')
  else
    # A/AAAA/CNAME mit proxied
    DATA=$(jq -n --arg type "$TYPE" --arg name "$NAME" --arg content "$CONTENT" \
               --argjson ttl "$TTL_VAL" --argjson proxied "$PROXIED" \
               '{type:$type,name:$name,content:$content,ttl:$ttl,proxied:$proxied}')
  fi

  # Existing Record abfragen
  local EXISTING_ID
  EXISTING_ID=$(
    curl -s -X GET "${CF_API_BASE}/zones/${ZONE_ID}/dns_records?type=${TYPE}&name=${NAME}" \
         -H "Authorization: Bearer ${CF_API_TOKEN}" \
         -H "Content-Type: application/json" \
      | jq -r '.result[0].id // empty'
  )

  if [[ -n "$EXISTING_ID" ]]; then
    curl -s -X PUT "${CF_API_BASE}/zones/${ZONE_ID}/dns_records/${EXISTING_ID}" \
         -H "Authorization: Bearer ${CF_API_TOKEN}" \
         -H "Content-Type: application/json" \
         --data "${DATA}" >/dev/null
    echo "Updated ${TYPE} ${NAME}"
  else
    curl -s -X POST "${CF_API_BASE}/zones/${ZONE_ID}/dns_records" \
         -H "Authorization: Bearer ${CF_API_TOKEN}" \
         -H "Content-Type: application/json" \
         --data "${DATA}" >/dev/null
    echo "Created ${TYPE} ${NAME}"
  fi
}

# ============================
# CHECKS
# ============================

[ -n "$DOMAIN" ] || err "Usage: $0 <domain.tld> (z.B. example.org)"

require_env CF_API_TOKEN
require_env MAILCOW_API_KEY
require_env MAILCOW_BASEURL

# ============================
# ZONE ID HOLEN
# ============================

echo "Suche Cloudflare Zone-ID für ${DOMAIN}..."
ZONE_ID=$(
  curl -s -X GET "${CF_API_BASE}/zones?name=${DOMAIN}" \
       -H "Authorization: Bearer ${CF_API_TOKEN}" \
       -H "Content-Type: application/json" \
    | jq -r '.result[0].id // empty'
)

[ -n "$ZONE_ID" ] || err "Konnte Zone-ID für ${DOMAIN} nicht finden. Stimmt die Domain in Cloudflare?"

echo "Gefundene Zone-ID: ${ZONE_ID}"

# ============================
# DKIM PER MAILCOW-API HOLEN
# ============================

echo "Hole DKIM-Key von Mailcow für ${DOMAIN}..."

DKIM_JSON=$(
  curl -s -X GET "${MAILCOW_BASEURL}/api/v1/get/dkim/${DOMAIN}" \
       -H "X-API-Key: ${MAILCOW_API_KEY}"
)

DKIM_SELECTOR=$(echo "$DKIM_JSON" | jq -r '.dkim_selector // "dkim"')
DKIM_TXT=$(echo "$DKIM_JSON" | jq -r '.dkim_txt // empty')

[ -n "$DKIM_TXT" ] || err "Kein DKIM-TXT von Mailcow erhalten. Prüfe API-Key, Domain oder ob ein DKIM-Key angelegt wurde."

DKIM_NAME="${DKIM_SELECTOR}._domainkey.${DOMAIN}"

echo "DKIM-Selector: ${DKIM_SELECTOR}"
echo "DKIM-Record:   ${DKIM_NAME}"

# ============================
# DNS-RECORDS ANLEGEN / AKTUALISIEREN
# ============================

echo "Lege Standard-Mailcow-DNS-Einträge für ${DOMAIN} an / aktualisiere sie..."

# MX
cf_upsert_record "MX" "${DOMAIN}" "${MAIL_HOST}" "${TTL}" "false" 10

# SPF
cf_upsert_record "TXT" "${DOMAIN}" "${SPF_VALUE}" "${TTL}"

# DKIM
cf_upsert_record "TXT" "${DKIM_NAME}" "${DKIM_TXT}" "${TTL}"

# DMARC
cf_upsert_record "TXT" "_dmarc.${DOMAIN}" "${DMARC_VALUE}" "${TTL}"

# Autoconfig / Autodiscover
cf_upsert_record "CNAME" "autoconfig.${DOMAIN}" "${MAIL_HOST}" "${TTL}" "false"
cf_upsert_record "CNAME" "autodiscover.${DOMAIN}" "${MAIL_HOST}" "${TTL}" "false"

# Optional: MTA-STS & TLS-RPT
cf_upsert_record "CNAME" "mta-sts.${DOMAIN}" "${MAIL_HOST}" "${TTL}" "false"
cf_upsert_record "TXT" "_mta-sts.${DOMAIN}" "v=STSv1; id=${MTA_STS_ID}" "${TTL}"
cf_upsert_record "TXT" "_smtp._tls.${DOMAIN}" "v=TLSRPTv1; rua=mailto:tls-reports@${DOMAIN}" "${TTL}"

echo "Fertig. Bitte DNS-Änderungen und Mailcow-Check-Tools (z.B. Mailcow DNS-Check, mail-tester.com) prüfen."

Beispiel-.env zum direkten Einsatz

export CF_API_TOKEN="xxxxxxx"
export MAILCOW_API_KEY="xxxxxxx"
export MAILCOW_BASEURL="https://mailcow.example.org"
export MAIL_HOST="mail.example.org"

The post Automatisches DNS-Setup mit Cloudflare- und Mailcow-API first appeared on NET73.

Ausgangslage (Beispiel)

Grundvoraussetzung für den nachfolgend beschriebenen Einsatz von gulp ist, dass bereits NodeJS und npm (oder yarn) in der Entwicklungsumgebung installiert sind.

Ein PHP-Web-Projekt sieht bei mir meistens so aus, dass ich im obersten Verzeichnis alle Umgebungs-Tools ablege (Dateien für Docker, Vagrant, etc.). Dort ist dann auch ein Verzeichnis „www“, in welchem das eigentliche Projekt liegt. In diesem Verzeichnis sind in der Wurzel dann die Dateien für die DEV-Tools (Composer, Node, Gulp, etc.), ein „app“-Verzeichnis, in welchem die PHP-Aktionen sind (MVC) und ein „public“-Verzeichnis, welches die „htdocs“ für die Webroot bereithält. Hier ist meistens nur eine index.php-Datei, welche die Core-Klasse(autoload) aus dem app-Verzeichnis lädt und eben die statischen Frontend-Dateien (js,css, scss, assets, fonts, etc.).

In der Übersicht sieht das dann so aus:

├── app ->
│   ├── init.php
│   ├── config ->
│   ├── controller ->
│   ├── library ->
│   ├── model ->
│   └── view ->
├── composer.json
├── composer.lock
├── composer.phar
├── gulpfile.js
(├── node_modules -> # wird erst mit "npm install" automatisch angelegt!)
├── package.json
├── package-lock.json
├── public ->
│   ├── css ->
│   ├── js ->
│   ├── fonts ->
│   ├── scss ->
│   └── index.php
└── Readme.md

Das Ziel ist hier also, dass die benötigten JS- und CSS-Dateien aus node_modules in das Frontend-Verzeichnis nach public/js und public/css überführt werden und die selbst geschriebenen SASS-Scripts aus public/scss mit den Scripts aus node_modules zusammen in public/css kompiliert werden (letzteres inkl. FileWatcher in Echtzeit.

Als Basis-Beispiel eine package.json-Datei, die bereits Gulp lokal via npm (oder yarn) installiert:

{
  "name": "n73-test",
  "version": "0.1.0",
  "description": "Test-Projekt zur gulp-Demonstration",
  "main": "public/index.php",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Pixel64",
  "license": "MIT",
  "dependencies": {
    "bootstrap": "^4.4.1",
    "jquery": "^3.4.1",
    "popper.js": "^1.16.1"
  },
  "devDependencies": {
    "browser-sync": "^2.26.7",
    "gulp": "^4.0.2",
    "gulp-sass": "^4.0.2"
  }
}

In diesem Projekt werden also die Pakete Bootstrap, JQuery und Popper gezogen und in das Verzeichnis node_modules gelegt.

GULP.JS

Mit der obigen Verzeichnisstruktur werden die Module via „npm install“ installiert (im Root-Verzeichnis, in welchem sich auch die package.json-Datei befindet).

Ist der Vorgang ausgeführt ist gulp _lokal_ installiert! Eine globale Installation von gulp(-cli) kann über den Paketmanager oder mit dem Schalter „-g“ erreicht werden (npm install -g gulp).

Die lokale Projekt-Installation reicht allerdings i.d.R. aus. Die installierte Version kann wie folgt geprüft werden:

./node_modules/.bin/gulp --version
CLI version: 2.2.0
Local version: 4.0.2

gulpfile.js

Die Anweisungen, was gulp im Verzeichnis erledigen soll, werden in der Datei gulpfile.js festgehalten. Eine Beispieldatei für das Test-Projekt sieht so aus:

var gulp        = require('gulp');
var browserSync = require('browser-sync').create();
var sass        = require('gulp-sass');

// SASS kompilieren, nach public/css verschieben und in browsersync aufnehmen
gulp.task('sass', function(){
    return gulp.src(['node_modules/bootstrap/scss/bootstrap.scss', 'public/scss/*.scss'])
        .pipe(sass())
        .pipe(gulp.dest('public/css'))
        .pipe(browserSync.stream());
});

//JS nach public/js verschieben
gulp.task('js', function(){
    return gulp.src([
        'node_modules/bootstrap/dist/js/bootstrap.min.js', 
        'node_modules/jquery/dist/jquery.min.js', 
        'node_modules/popper.js/dist/umd/popper.min.js'])
        .pipe(gulp.dest('public/js'))
        .pipe(browserSync.stream());
});



//Fonts nach public/fonts schieben
gulp.task('fonts', function(){
    return gulp.src('node_modules/font-awesome/fonts/*')
        .pipe(gulp.dest('public/fonts'));
});

//fontawesome nach public/css verschieben
gulp.task('fa', ()=>{
    return gulp.src('node_modules/font-awesome/css/font-awesome.min.css')
        .pipe(gulp.dest('public/css'))
        .pipe(browserSync.stream());
});

// SASS ueberwachen und bei Veraenderungen kompilieren
gulp.task('serve', gulp.series('sass', function() {
    browserSync.init({
	    proxy: 'http://localhost/',
	    notify: true,
    });

    gulp.watch(['node_modules/bootstrap/scss/bootstrap.scss', 'scss/*.scss'], gulp.series('sass'))
    gulp.watch('*.php').on('change', browserSync.reload);
}));


gulp.task('default', gulp.series('js', 'serve', 'fa', 'fonts'));%

Ist diese Datei erstellt, reicht ein einfacher Aufruf von ./node_modules/.bin/gulp und der Vorgang startet. Jetzt werden die entsprechenden Scripts kopiert und ein aktiver FileWatcher überwacht SASS und kompiliert bei Veränderungen scss nach css. Zudem werden die Veränderungen an den definierten Dateien im www-Verzeichnis über einen lokalen Server (Port 3000) angezeigt (index.php oder index.html, je nach Projekt). Letzteres wird durch den gulp-task „server“ organisiert und kann bei Bedarf oder Nutzung anderer Entwicklungsumgebungen deaktiviert werden (Docker- oder Vagrant-Umgebung?).

Zusatz

Natürlich kann gulp auch in komplett statischen Umgebungen eingesetzt werden. Generell müssen jeweils nur die Verzeichnisse an die eigene Projektstruktur angepasst werden.

Über die package.json-Datei kann jeweils kontrolliert werden, welche Versionen von Bootstrap, JQuery & Co. geladen werden sollen und den Weg ins eigene Web-Projekt finden. Die so erstellten CSS- und JS-Dateien können dann wie gewohnt aus dem /js- und /css-Verzeichnis in die eigenen Web-Dateien (PHP->Views, oder HTML-Dateien->statisch) eingebunden werden.

Für das Deployment im Produktiv-Betrieb ist somit auch kein einzelnes Zusammensuchen der Bibliotheken notwendig und auch kein Überwachen der statisch eingebundenen CDN-Links im Projekt notwendig (kann man trotzdem parallel nutzen).

The post CSS und JavaScript mit NPM und Gulp organisieren first appeared on NET73.