Netlify Build Plugins Ankündigung

❥ Sponsor

Netlify hat gerade ein neues Ding veröffentlicht: Build Plugins. (Es ist noch in der Beta, daher müssen Sie derzeit Zugang beantragen.) Hier ist mein Versuch, es zu erklären, was stark von David Wells' Ankündigungsvideo beeinflusst ist.

Sie denken vielleicht, dass Netlify der Dienst ist, der es einfach macht, einige statische Dateien aus einem Repository hochzuladen und eine Produktionsseite blitzschnell zu haben. Sie liegen nicht falsch. Aber lassen Sie uns einen Schritt zurücktreten und das betrachten. Netlify versteht sich selbst als Plattform in drei Ebenen

  1. Netlify Build
  2. Netlify Dev
  3. Netlify Edge

Die meisten Dinge, die Netlify tut, fallen in diese Kategorien. Verbindung Ihres Git-Repositorys und Zulassen, dass Netlify die Website erstellt und bereitstellt? Das ist Build. Verwendet die CLI von Netlify, um die lokale Entwicklungsumgebung hochzufahren und Dinge wie das Testen lokaler Funktionen zu tun? Das ist Dev. Das aufgerüstete CDN, das tatsächlich unsere Produktionsseiten betreibt? Das ist Edge. Sehen Sie sich die Produktseite für diese Aufschlüsselung an.

Selbst wenn Sie nur einige Dateien hochladen, die aus einem Static-Site-Generator stammen, nutzen Sie wahrscheinlich immer noch all diese Ebenen. Build kümmert sich um die Git-Verbindung und führt möglicherweise npm run build oder etwas Ähnliches aus. Möglicherweise führen Sie netlify dev lokal aus, um Ihren lokalen Entwicklungsserver auszuführen. Und die Live-Seite wird von Edge verwaltet.

Mit dieser neuen Version von Build Plugins öffnet Netlify den Zugriff auf die Funktionsweise von Build. Es ist nicht mehr nur "Verbindung zum Repository herstellen und diesen Befehl ausführen, wenn der Build läuft." Es gibt tatsächlich einen ganzen Lebenszyklus von Dingen, die während eines Builds passieren. So beschrieb David diesen Lebenszyklus

  1. Build beginnt
  2. Cache wird abgerufen
  3. Abhängigkeiten werden installiert
  4. Build-Befehle werden ausgeführt
  5. Serverless Functions werden erstellt
  6. Cache wird gespeichert
  7. Bereitstellung
  8. Nachbearbeitung

Was wäre, wenn Sie diese Lebenszyklusereignisse nutzen und Ihren eigenen Code parallel dazu ausführen könnten? Das ist die Idee hinter Build Plugins. Tatsächlich sind diese Lebenszyklusereignisse buchstäblich Event-Hooks. Sarah Drasner listete sie mit ihren offiziellen Namen in ihrem Einführungsblog-Post auf

  • init: wenn der Build beginnt
  • getCache: ruft den Cache des letzten Builds ab
  • install: wenn die Abhängigkeiten des Projekts installiert werden
  • preBuild: wird direkt vor dem Erstellen der Funktionen und dem Ausführen der Build-Befehle ausgeführt
  • functionsBuild: wird ausgeführt, wenn die Serverless Functions erstellt werden, falls sie auf der Website vorhanden sind
  • build: wenn die Build-Befehle ausgeführt werden
  • package: wird für die Bereitstellung verpackt
  • preDeploy: wird ausgeführt, bevor das erstellte Paket bereitgestellt wird
  • saveCache: speichert gecachte Assets
  • finally: Build abgeschlossen, Website bereitgestellt 🚀

Um diese Hooks zu nutzen und Ihren eigenen Code während des Builds auszuführen, schreiben Sie ein Plugin (in Node JavaScript) und legen Sie es in einen Plugins-Ordner, z. B. ./plugins/myPlugin/index.js

function netlifyPlugin(config) {
  return {
    name: 'my-plugin-name',
    init: () => {
      console.log('Hi from init')
    },
  }
}

module.exports = netlifyPlugin

…und passen Sie Ihre Netlify-Konfiguration (Datei) an, um darauf zu verweisen. Am besten lesen Sie Sarahs Beitrag für alle Details und Beispiele.

OK. Was ist der Sinn der Sache?

Das ist der entscheidende Teil, oder? Das Einzige, was wirklich zählt. Kontrolle zu haben ist toll und so, aber es zählt nur, wenn es tatsächlich nützlich ist. Was können wir also tun, jetzt wo wir Teile des Build-Prozesses auf der Plattform selbst nutzen können, um unser Leben und unsere Websites besser zu machen?

Hier sind einige Ideen, die ich bisher gesammelt habe.

Sitemaps

David hat demonstriert, wie der Build-Prozess eine Sitemap erstellt. Sitemaps sind großartig (für SEO), aber ich verschwende definitiv keine Zeit damit, sie lokal sehr oft zu erstellen, und sie müssen nicht wirklich in meinem Repository sein. Lassen Sie die Plattform das machen und die Datei als "Build-Artefakt" live stellen. Sie können dies für alles tun (z. B. mein lokaler Build-Prozess muss CSS und dergleichen kompilieren, sodass ich lokal arbeiten kann), aber wenn die Produktion Dateien benötigt, die lokal nicht benötigt werden, ist dies eine gute Lösung.

Benachrichtigungen

Sarah demonstrierte ein Plugin, das eine Twilio API aufruft, um eine SMS zu senden, wenn ein Build abgeschlossen ist. Ich mache dasselbe, indem ich Buddy eine Slack-Nachricht senden lasse, wenn die Bereitstellung dieser Website abgeschlossen ist. Man kann sich vorstellen, wie die Teamkommunikation durch solche programmatischen Nachrichten erleichtert werden kann.

Leistungsüberwachung

Die Build-Zeit ist ein großartiger Zeitpunkt, um Leistungskennzahlen zu ermitteln. Netlify sagt, sie arbeiten an einem Plugin, um Ihren Lighthouse-Score zwischen den Bereitstellungen zu verfolgen. Warum nicht Ihr SpeedCurve CLI-Ding oder Build Tracker CLI dort ausführen, um zu sehen, ob Sie Ihr Leistungsbudget überschritten haben?

Optimierungen

Warum nicht die Build-Zeit nutzen, um alle Ihre Bildoptimierungen durchzuführen? Image Optim bietet eine API, die Sie aufrufen könnten. SVGO funktioniert auf der Kommandozeile und Netlify sagt, dass sie bereits an diesem Plugin arbeiten. Ich denke, einige dieser Dinge möchten Sie in Ihrem lokalen Build-Prozess ausführen (z. B. Bild in Ordner legen, Gulp wacht, Bild wird optimiert), aber denken Sie daran, dass Sie netlify dev lokal ausführen können, was Ihre Build-Schritte lokal ausführt, und Sie könnten auch Ihr Gulp so organisieren, dass der Code, der die Bildoptimierung durchführt, Teil eines Watch-Prozesses sein kann oder während eines Builds explizit aufgerufen werden kann.

Bilder sind ein fantastisches Ziel für Optimierungen, aber praktisch jede Ressource kann in irgendeiner Weise optimiert werden!

Abbrechen problematischer Builds

Wenn Ihr Build-Prozess fehlschlägt, stellt Netlify ihn bereits nicht bereit. Klar nützlich. Aber jetzt könnten Sie diesen Fehler selbst auslösen. Was wäre, wenn die Leistungsüberwachung nicht nur berichtet, was passiert, sondern den Build buchstäblich abbricht, wenn ein Budget nicht eingehalten wird? Alles, was Sie tun müssen, ist, einen Fehler auszulösen oder process.exit, wie ich höre.

Noch besser, wie wäre es, einen Build bei einer Rückschritt bei der Barrierefreiheit fehlschlagen zu lassen? Netlify arbeitet an einem Axe-Plugin für Audits.

Offensichtlich könnten Sie abbrechen, wenn Ihre Unit-Tests (z. B. Jest) fehlschlagen oder Ihre End-to-End-Tests (z. B. Cypress) fehlschlagen, was bedeutet, dass Sie auf 404s und alle Arten von benutzerseitigen Problemen achten und problematische Bereitstellungen vollständig verhindern könnten.

Nutzen Sie diesen Build

Netlify setzt klar auf das JAMstack-Konzept. Einiges davon ist ziemlich offensichtlich. Werfen Sie einige statische Dateien auf ein Killer-CDN und die Website hat eine wunderbar schnelle Grundlage. Einiges davon ist weniger offensichtlich. Wenn Sie immer noch serverseitigen Code benötigen, haben Sie diesen immer noch in Form von Cloud-Funktionen, die wahrscheinlich leistungsfähiger sind, als die meisten Leute denken. Einiges davon erfordert, dass Sie Ihre Website auf neue Weise betrachten, wie die Tatsache, dass das Vortoken von Markup keine Alles-oder-Nichts-Entscheidung ist. Sie können so viel wie möglich erstellen und die clientseitige Arbeit für Dinge überlassen, die für die Client-Seite praktischer sind (z. B. personalisierte Informationen). Wenn Sie Ihren Build-Prozess als ein leistungsstarkes und flexibles Werkzeug betrachten, um so viel Arbeit wie möglich auszulagern, ist das ein großartiger Ausgangspunkt.