BackZurück zum Blog

Next.js 9.5

Next.js 9.5 führt stabile inkrementelle statische Regeneration, benutzerdefinierte Basis-Pfade, Weiterleitungen und Rewrites, Webpack 5 Beta und mehr ein!

Wir freuen uns, heute Next.js 9.5 mit folgenden Features vorstellen zu können:

Stabile inkrementelle statische Regeneration

Next.js hat in Version 9.3 Methoden zur Generierung statischer Websites mit einem klaren Ziel eingeführt: Wir sollten die Vorteile statischer Seiten (immer schnell, immer online, global repliziert) erhalten, aber mit exzellenter Unterstützung für dynamische Daten, für die Next.js bekannt ist.

Um das Beste aus beiden Welten zu vereinen, hat Next.js Inkrementelle Statische Generierung eingeführt, die statische Inhalte aktualisiert, nachdem Ihre Website bereits gebaut wurde. Durch Verwendung der fallback: true Option in getStaticPaths können Sie neue statische Seiten zur Laufzeit registrieren.

Next.js kann auf diese Weise eine unbegrenzte Anzahl von Seiten statisch vorrendern, on-demand, egal wie groß Ihr Datensatz ist.

Heute kündigen wir die allgemeine Verfügbarkeit der Inkrementellen Statischen Regeneration an, einem Mechanismus zum Aktualisieren bestehender Seiten, indem sie im Hintergrund neu gerendert werden, während Traffic eintrifft.

Inspiriert von stale-while-revalidate stellt die Hintergrund-Regeneration sicher, dass Traffic ununterbrochen aus statischem Speicher bedient wird und die neu gebaute Seite erst nach Abschluss der Generierung ausgeliefert wird.

export async function getStaticProps() {
  return {
    props: await getDataFromCMS(),
    // Die Seite wird neu generiert:
    // - bei einer eingehenden Anfrage
    // - höchstens einmal pro Sekunde
    revalidate: 1,
  };
}

Das revalidate-Flag gibt die Anzahl der Sekunden an, in denen höchstens eine Generierung stattfindet, um eine Cache Stampede zu verhindern.

Im Gegensatz zu traditionellem SSR (Server-Side Rendering) stellt die inkrementelle statische Regeneration sicher, dass Sie die Vorteile statischer Seiten behalten:

  • Keine Latenzspitzen. Seiten werden konsistent schnell ausgeliefert.
  • Seiten gehen nie offline. Wenn die Hintergrund-Regeneration fehlschlägt, bleibt die alte Seite unverändert.
  • Geringe Belastung von Datenbank und Backend. Seiten werden höchstens einmal gleichzeitig neu berechnet.

Beide inkrementellen Features (Hinzufügen von Seiten und deren verzögerte Aktualisierung) sowie der Vorschaumodus sind jetzt stabil und werden sowohl von next start als auch von der Vercel Edge Platform out-of-the-box vollständig unterstützt.

Um dieses neue Feature zu demonstrieren, haben wir ein Beispiel erstellt, das die Regeneration einer statischen Seite zeigt, die die Anzahl verschiedener GitHub-Reaktionen auf ein bestimmtes Issue anzeigt: https://reactions-demo.vercel.app/

Nach dem ersten Besuch nach unserer Emoji-Reaktion startet eine neue Seitengenerierung im Hintergrund. Jede einzelne Anfrage wird währenddessen aus dem statischen Cache bedient.

Nach dem ersten Besuch nach unserer Emoji-Reaktion startet eine neue Seitengenerierung im Hintergrund. Jede einzelne Anfrage wird währenddessen aus dem statischen Cache bedient.

Als nächstes arbeiten wir an einem ergänzenden RFC, um zwei weitere Fähigkeiten der inkrementellen statischen Generierung zu adressieren:

  • Gleichzeitige Regeneration und Invalidierung mehrerer Seiten (z.B. Ihr Blog-Index und ein bestimmter Blog-Post)
  • Regeneration durch Abhören von Ereignissen (wie CMS-Webhooks), bevor Nutzer-Traffic eintrifft

Für weitere Details lesen Sie die getStaticProps Dokumentation.

Anpassbarer Basis-Pfad

Next.js-Projekte werden nicht immer von der Root einer Domain aus bedient. Manchmal möchten Sie Ihr Next.js-Projekt unter einem Unterpfad wie /docs hosten, sodass das Next.js-Projekt nur diesen Teilbereich der Domain abdeckt.

Während dies bisher möglich war, erforderte es erhebliche zusätzliche Konfiguration. Zum Beispiel das Hinzufügen des Präfixes zu jedem einzelnen <Link> und das Sicherstellen, dass Next.js die JavaScript-Bundles vom richtigen Pfad aus liefert.

Um diesen Schmerzpunkt zu beseitigen, führen wir eine neue Konfigurationsoption ein. basePath ermöglicht es Ihnen, Ihr Next.js-Projekt einfach auf einem Unterpfad Ihrer Domain zu hosten.

Um basePath zu verwenden, können Sie es in next.config.js hinzufügen:

next.config.js
module.exports = {
  basePath: '/docs',
};

Nach der Konfiguration von basePath wird Ihr Projekt automatisch vom angegebenen Pfad aus geroutet. In diesem Fall /docs.

Wenn Sie mit next/link oder next/router auf andere Seiten im Projekt verlinken, wird der basePath automatisch vorangestellt. Dies ermöglicht es Ihnen, den basePath zu ändern, ohne Ihr Projekt anzupassen.

Ein Beispiel hierfür wäre die Verwendung von next/link zum Routen zu einer anderen Seite:

import Link from 'next/link';
 
export default function HomePage() {
  return (
    <>
      <Link href="/documentation-page">
        <a>Dokumentationsseite</a>
      </Link>
    </>
  );
}

Die Verwendung von next/link auf diese Weise führt zu folgendem HTML im Browser:

<a href="/docs/documentation-page">Dokumentationsseite</a>

Für weitere Details lesen Sie die basePath Dokumentation.

Unterstützung für Rewrites, Weiterleitungen und Header

Rewrites

Beim Erstellen eines Next.js-Projekts möchten Sie möglicherweise bestimmte Routen an eine andere URL weiterleiten. Zum Beispiel, wenn Sie Next.js schrittweise in Ihren Stack integrieren möchten, würden Sie Seiten routen, die in Ihrem Next.js-Projekt existieren, und alles andere an das alte Projekt weiterleiten, von dem Sie migrieren.

Mit Next.js 9.5 führen wir eine neue Konfigurationsoption namens rewrites ein, die es Ihnen ermöglicht, einen eingehenden Anfragepfad einem anderen Zielpfad zuzuordnen, einschließlich externer URLs.

Zum Beispiel möchten Sie möglicherweise eine bestimmte Route an example.com weiterleiten:

next.config.js
module.exports = {
  async rewrites() {
    return [
      { source: '/backend/:path*', destination: 'https://example.com/:path*' },
    ];
  },
};

In diesem Fall würden alle Pfade unter /backend an example.com geroutet.

Sie können auch überprüfen, ob Ihre Next.js-Projekt-Routen übereinstimmen, und dann an das vorherige Projekt weiterleiten, wenn keine Übereinstimmung vorliegt. Dies ist äußerst nützlich für die schrittweise Einführung von Next.js:

module.exports = {
  async rewrites() {
    return [
      // Zuerst prüfen, ob Next.js-Projekt-Routen übereinstimmen
      {
        source: '/:path*',
        destination: '/:path*',
      },
      {
        source: '/:path*',
        destination: `https://example.com/:path*`,
      },
    ];
  },
};

In diesem Fall stimmen wir zuerst alle Pfade ab. Wenn keine übereinstimmen, leiten wir an example.com weiter, was das vorherige Projekt wäre.

Um mehr über das rewrites-Feature zu erfahren, lesen Sie die Rewrites-Dokumentation.

Weiterleitungen

Die meisten Websites benötigen mindestens einige Weiterleitungen. Besonders bei Änderungen der Projekt-Routenstruktur. Zum Beispiel beim Verschieben von /blog zu /news oder ähnlichen Übergängen.

Bisher erforderte eine Liste von Weiterleitungen in Ihrem Next.js-Projekt die Einrichtung eines Custom Servers oder einer benutzerdefinierten _error-Seite, um zu prüfen, ob Weiterleitungen für die Route festgelegt sind. Dies ging jedoch auf Kosten wichtiger statischer und serverloser Optimierungen (durch einen Server) oder war nicht ergonomisch genug.

Ab Next.js 9.5 können Sie jetzt eine Liste von Weiterleitungen in next.config.js unter dem Schlüssel redirects erstellen:

next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/about',
        destination: '/',
        permanent: true,
      },
    ];
  },
};

Um mehr über das redirects-Feature zu erfahren, lesen Sie die Weiterleitungs-Dokumentation.

Headers

Next.js ermöglicht es Ihnen, hybride Projekte zu erstellen, die sowohl statische Generierung als auch serverseitiges Rendering (Server-Side Rendering, SSR) nutzen. Mit serverseitigem Rendering können Sie Header für eingehende Anfragen setzen. Für statische Seiten war das Setzen von Headern bisher nicht möglich.

Wir haben nun eine headers-Eigenschaft in next.config.js eingeführt, die für alle Next.js-Routen gilt:

next.config.js
module.exports = {
  async headers() {
    return [
      {
        source: '/:path*',
        headers: [
          {
            key: 'Feature-Policy',
            // Mikrofon und Geolokalisierung deaktivieren
            value: "microphone 'none'; geolocation 'none'",
          },
        ],
      },
    ];
  },
};

Die headers-Option ermöglicht es Ihnen, häufig benötigte Header wie Feature-Policy und Content-Security-Policy zu setzen.

Weitere Informationen zur headers-Funktion finden Sie in der Header-Dokumentation.

Optionale abschließende Schrägstriche in URLs

Als Next.js vor 3 Jahren eingeführt wurde, war das Standardverhalten, dass alle URLs mit einem abschließenden Schrägstrich immer eine 404-Seite zurückgaben.

Obwohl effektiv, haben einige Benutzer die Möglichkeit gewünscht, dieses Verhalten zu ändern. Zum Beispiel beim Migrieren eines bestehenden Projekts zu Next.js, das zuvor immer abschließende Schrägstriche erzwungen hat.

Mit Next.js 9.5 haben wir eine neue Option namens trailingSlash in next.config.js eingeführt.

Diese neue Option stellt sicher, dass Next.js das Verhalten für abschließende Schrägstriche automatisch handhabt:

  • Automatische Weiterleitung von URLs mit abschließendem Schrägstrich zur URL ohne Schrägstrich, z.B.: /about/ zu /about
  • Wenn trailingSlash auf true gesetzt ist, wird die URL ohne Schrägstrich zur URL mit Schrägstrich weitergeleitet, z.B.: /about zu /about/
  • Stellt sicher, dass next/link den Schrägstrich automatisch hinzufügt/entfernt, um unnötige Weiterleitungen zu vermeiden.
next.config.js
module.exports = {
  // Erzwingt einen abschließenden Schrägstrich, der Standardwert ist kein Schrägstrich (false)
  trailingSlash: true,
};

Weitere Informationen zur trailingSlash-Funktion finden Sie in der trailingSlash-Dokumentation

Persistenter Cache für Seiten-Bundles

Beim Erstellen von Next.js-Seiten ist die Generierung aller Skript-Bundles, CSS-Stylesheets und HTML vollautomatisch und für Sie abstrahiert. Wenn Sie die generierten <script>-Tags vor Next.js 9.5 untersuchen, werden Sie feststellen, dass ihre URLs einem Muster wie diesem folgen:

/_next/static/ovgxWYrvKyjnlM15qtz7h/pages/about.js

Das Pfadsegment ovgxWYrvKyjnlM15qtz7h oben ist die sogenannte Build-ID. Obwohl diese Dateien leicht am Edge und auf dem Rechner des Benutzers zwischengespeichert werden konnten, änderte sich die Build-ID nach einem Rebuild Ihrer App, und alle Caches wurden ungültig.

Für die meisten Projekte war dieser Kompromiss in Ordnung, aber wir wollten dieses Verhalten noch weiter optimieren, indem wir den Browser-Cache für Seiten, die sich nicht geändert haben, nicht mehr invalidieren.

Die Einführung der verbesserten Code-Splitting-Strategie in Next.js 9.2, die in Zusammenarbeit mit dem Google Chrome-Team entwickelt wurde, legte den Grundstein für diese Verbesserungen bei der Generierung von Next.js-Seiten-Bundles.

Ab Next.js 9.5 verwenden alle Seiten-JavaScript-Bundles Inhalts-Hashes anstelle der Build-ID. Dadurch können Seiten, die sich zwischen Deployments nicht geändert haben, im Browser- und Edge-Cache bleiben, ohne erneut heruntergeladen werden zu müssen.

Im Gegensatz dazu sieht das URL-Muster nach diesen Änderungen etwa so aus:

/_next/static/chunks/pages/about.qzfS4o5gIEXRME6sTEahL.js

Anstelle einer globalen Build-ID ist der Teil `qzfS4o5gIEXRME6sTEahL` ein deterministischer Hash des `about.js`-Bundles, der stabil bleibt, solange sich der Code für diesen Teil Ihrer Website nicht ändert. Darüber hinaus wird er **jetzt langfristig über Re-Deployments hinweg zwischengespeichert** durch `Cache-Control: public,max-age=31536000,immutable`, das Next.js automatisch für Sie setzt.

[Verbesserungen bei Fast Refresh](#fast-refresh-enhancements)
-------------------------------------------------------

Wir haben [Fast Refresh in Next.js 9.4 eingeführt](https://nextjs.org/blog/next-9-4#fast-refresh), eine neue Hot-Reloading-Erfahrung, die Ihnen sofortiges Feedback auf Änderungen an Ihren React-Komponenten gibt.

Next.js 9.5 verfeinert unsere Fast-Refresh-Implementierung weiter und gibt Ihnen die Werkzeuge an die Hand, die Sie für den Erfolg benötigen:

*   **Einfach verständliche Fehler**: Alle Kompilierungs- und Laufzeitfehler wurden aktualisiert, um [nur **relevante Informationen anzuzeigen, einschließlich eines Code-Frames** des Codes, der den Fehler verursacht hat](https://twitter.com/timer150/status/1263689549898829829).
*   **Entwicklungstipps zur Beibehaltung des Komponentenzustands**: Next.js bietet Ihnen jetzt hilfreiche Tipps, um sicherzustellen, dass Fast Refresh Ihren Komponentenzustand in möglichst vielen Szenarien beibehält. Jeder von Next.js bereitgestellte Tipp ist **vollständig umsetzbar** und wird von einem Vorher-Nachher-Beispiel begleitet!
*   **Warnungen bei Zurücksetzen des Komponentenzustands**: Wir werden jetzt eine detaillierte Warnung ausgeben, wenn Next.js den Komponentenzustand nach einer Dateiänderung nicht beibehalten kann. Diese Warnung hilft Ihnen, den Grund für das Zurücksetzen des Zustands zu diagnostizieren, sodass Sie das Problem beheben und Fast Refresh optimal nutzen können.
*   **Neue Dokumentation**: Wir haben [umfangreiche Dokumentation hinzugefügt](/docs/architecture/fast-refresh), die erklärt, was Fast Refresh ist, wie es funktioniert und was Sie erwarten können! Die Dokumentation zeigt Ihnen auch, wie Sie Fast Refresh besser nutzen können, indem sie erklärt, wie die Fehlerbehebung funktioniert.
*   **Fehlerbehebungsleitfaden für Benutzercode**: Die neue Dokumentation enthält auch [häufige Schritte zur Fehlerbehebung und Tipps](/docs/architecture/fast-refresh#tips), wie Sie das Beste aus Fast Refresh in der Entwicklung herausholen können.

[React Profiling in der Produktion](#production-react-profiling)
---------------------------------------------------------

React hat vor einiger Zeit die [Profiler API](https://github.com/reactjs/rfcs/pull/51) eingeführt, mit der Sie Leistungsprobleme in Ihren React-Komponenten aufspüren können. Während diese Funktion in der Entwicklung automatisch funktioniert, erfordert sie eine separate Version von ReactDOM, um in der Produktion profilen zu können.

Mit Next.js 9.5 können Sie jetzt **React Profiling in der Produktion** mit dem `--profile`-Flag in `next build` aktivieren:

next build --profile


Danach können Sie den Profiler genauso verwenden wie in der Entwicklung.

Weitere Informationen zum Profiling mit React finden Sie im [Beitrag zum React Profiler vom React-Team](https://reactjs.org/blog/2018/09/10/introducing-the-react-profiler.html). Besonderer Dank geht an [TODOrTotev](https://github.com/TodorTotev) und [@darshkpatel](https://github.com/darshkpatel) für ihren Beitrag zu dieser Funktion.

[Optionale Catch-All-Routen](#optional-catch-all-routes)
-------------------------------------------------------

Next.js 9.2 hat [Unterstützung für Catch-All-Dynamische Routen](https://nextjs.org/blog/next-9-2#catch-all-dynamic-routes) hinzugefügt, die von der Community für verschiedene Anwendungsfälle weitgehend übernommen wurden. Catch-All-Routen geben Ihnen die Flexibilität, hochdynamische Routing-Strukturen zu erstellen, die von Headless CMS, GraphQL APIs, Dateisystemen usw. angetrieben werden.

Aufgrund von Feedback haben wir gehört, dass Benutzer noch mehr Flexibilität wollten, um _die oberste Ebene einer Route abzugleichen_. Heute freuen wir uns, **optionale Catch-All-Dynamische Routen** für diese fortgeschrittenen Szenarien vorzustellen.

Um eine optionale Catch-All-Route zu erstellen, können Sie eine Seite mit der Syntax `[[...slug]]` erstellen.

Zum Beispiel wird `pages/blog/[[...slug]].js` auf `/blog` sowie auf jede darunter liegende Route passen, wie z.B.: `/blog/a`, `/blog/a/b/c`, usw.

Wie bei Catch-All-Routen wird `slug` im [Router Query-Objekt](/docs/pages/api-reference/functions/use-router#router-object) als Array von Pfadteilen bereitgestellt. Für den Pfad `/blog/foo/bar` wird das Query-Objekt also `{ slug: ['foo', 'bar'] }` sein. Für den Pfad `/blog` wird das Query-Objekt den `slug`-Schlüssel weglassen: `{ }`.

Sie können [mehr über optionale Catch-All-Routen in unserer Dokumentation erfahren](/docs/pages/building-your-application/routing/dynamic-routes#optional-catch-all-routes).

[Webpack 5 Unterstützung (Beta)](#webpack-5-support-beta)
---------------------------------------------------

Webpack 5 befindet sich derzeit in der Beta-Phase. Es enthält einige wichtige Verbesserungen:

*   [Verbessertes Tree-Shaking](https://github.com/webpack/changelog-v5#nested-tree-shaking): Verschachtelte Exporte, innere Module und CommonJS werden optimiert
*   [Persistenter Cache](https://github.com/webpack/changelog-v5#persistent-caching): Ermöglicht die Wiederverwendung von Arbeit aus vorherigen Builds
*   [Deterministische Chunk- und Modul-IDs](https://github.com/webpack/changelog-v5#deterministic-chunk-and-module-ids): Behebt Fälle, in denen sich Webpack-Modul-IDs zwischen Builds ändern würden

Wir freuen uns, heute die Beta-Verfügbarkeit von Webpack 5 für Next.js bekannt zu geben.

Um Webpack 5 auszuprobieren, können Sie [Yarn resolutions](https://classic.yarnpkg.com/en/docs/selective-version-resolutions/) in Ihrer `package.json` verwenden:

```json filename="package.json"
{
  "resolutions": {
    "webpack": "^5.0.0-beta.30"
  }
}

Die Webpack 5 Beta wurde bereits in Produktion auf nextjs.org und vercel.com ausgerollt. Wir ermutigen Sie, sie schrittweise auszuprobieren und Ihre Ergebnisse auf GitHub zu melden.

Verbesserungen an der Kompilierungsinfrastruktur

Um Webpack 5 zu unterstützen, haben wir große Teile der Kompilierungspipeline neu geschrieben, um sie besser auf Next.js abzustimmen:

  • Next.js verlässt sich nicht mehr auf webpack-hot-middleware und webpack-dev-middleware, stattdessen verwenden wir Webpack jetzt direkt und optimieren speziell für Next.js-Projekte. Dies führt zu einer einfacheren Architektur und schnellerer Entwicklungskompilierung.
  • On-Demand-Entries, das System von Next.js, das es ermöglicht, während der Entwicklung nur die Seiten zu kompilieren, die Sie zu einem bestimmten Zeitpunkt besuchen, wurde ebenfalls neu geschrieben und ist jetzt noch zuverlässiger durch die Nutzung von neuem Webpack-Verhalten, das speziell für unseren Anwendungsfall zugeschnitten ist.
  • React Fast Refresh und das Next.js Error Overlay sind jetzt vollständig mit Webpack 5 kompatibel
  • Die Festplatten-Caching-Funktion wird in einer zukünftigen Beta-Version aktiviert.

Abwärtskompatibilität

Wir sind stets bestrebt, sicherzustellen, dass Next.js abwärtskompatibel mit früheren Versionen ist.

Webpack 4 wird weiterhin vollständig unterstützt. Wir arbeiten eng mit dem Webpack-Team zusammen, um sicherzustellen, dass die Migration von Webpack 4 auf 5 so reibungslos wie möglich verläuft.

Wenn Ihr Next.js-Projekt keine benutzerdefinierte Webpack-Konfiguration hat, sind keine Projektänderungen erforderlich, um Webpack 5 vollständig nutzen zu können.

Wichtig: Wenn Ihr Projekt eine benutzerdefinierte Webpack-Konfiguration hat, könnten einige Änderungen für den Übergang zu Webpack 5 erforderlich sein. Wir empfehlen, unsere Migrationsanleitungen im Auge zu behalten oder die Verwendung von Webpack-Erweiterungen insgesamt zu minimieren, um zukünftige Upgrades problemlos zu gestalten.

Verbessertes Datei-Monitoring auf macOS

Wir haben kürzlich ein Problem mit Webpack festgestellt, bei dem das Datei-Monitoring auf macOS nach einigen Änderungen an Ihrem Code stoppen würde. Sie müssten Ihr Projekt manuell neu starten, um Updates wieder zu sehen. Nach einigen Änderungen würde sich der Zyklus wiederholen.

Darüber hinaus haben wir festgestellt, dass dieses Problem nicht nur in Next.js-Projekten auftrat, sondern in allen Projekten und Frameworks, die auf Webpack aufbauen.

Nach mehreren Tagen der Fehlersuche haben wir die Ursache auf die Datei-Monitoring-Implementierung zurückgeführt, die Webpack verwendet, genannt chokidar, eine weit verbreitete Datei-Monitoring-Implementierung in der Node.js-Ökosystem.

Wir haben einen Patch an chokidar gesendet, um das Problem zu beheben. Nach der Veröffentlichung des Patches haben wir mit Tobias Koppers zusammengearbeitet, um diesen Patch in einer neuen Webpack-Version auszurollen.

Diese gepatchte Webpack-Version wird automatisch verwendet, wenn Sie auf Next.js 9.5 aktualisieren.

Fazit

Wir freuen uns über das anhaltende Wachstum der Next.js-Adaption:

  • Wir haben über 1.200 unabhängige Mitwirkende**,** mit über 135 neuen Mitwirkenden seit der Version 9.4.
  • Auf GitHub wurde das Projekt über 51.100 Mal mit einem Stern versehen.

Treten Sie der Next.js-Community auf GitHub Discussions bei. Discussions ist ein Community-Bereich, der es Ihnen ermöglicht, sich mit anderen Next.js-Benutzern zu verbinden und Fragen zu stellen oder Ihre Arbeit zu teilen.

Sie könnten zum Beispiel damit beginnen, Ihre Projekt-URL mit allen zu teilen.

Wenn Sie etwas zurückgeben möchten, aber unsicher sind wie, ermutigen wir Sie, experimentelle Funktionen wie unsere Webpack-Unterstützung auszuprobieren und Ihre Ergebnisse zu melden!

Danksagungen

Wir sind unserer Community dankbar, einschließlich aller externen Feedbacks und Beiträge, die diese Version mitgestaltet haben.

Besonderer Dank geht an Jan Potoms, ein langjähriges Mitglied der Next.js-Community, das zu mehreren Funktionen in dieser Version beigetragen hat.

Besonderer Dank geht an Tobias Koppers, den Autor von Webpack, der geholfen hat, die Webpack 5-Unterstützung in Next.js zu integrieren.

Diese Version wurde durch die Beiträge von ermöglicht: @chandan-reddy-k, @Timer, @aralroca, @artemisart, @sospedra, @prateekbh, @Prioe, @Janpot, @merceyz, @ijjk, @PavelK27, @marbiano, @MichelleLucero, @thorsten-stripe, @TODOrTotev, @Skn0tt, @lfades, @timneutkens, @akhila-ariyachandra, @chibicode, @rafaelalmeidatk, @kirill-konshin, @jamesvidler, @JeffersonBledsoe, @tylev, @jamesmosier, @filipemarins, @Remeic, @vvo, @timothyis, @jazibsawar, @coetry, @adam-zacharski, @danwilliams, @tywmick, @matamatanot, @goldins, @mvllow, @its-tayo, @sshyam-gupta, @wilbert-abreu, @sebastianbenz, @jaydenseric, @developit, @dylanjha, @darshkpatel, @spinks, @stefanprobst, @moh12594, @jasonmerino, @cristiand391, @HyunSangHan, @mcsdevv, @M1ck0, @hydRAnger, @alexej-d, @valmassoi, @motleydev, @eKhattak, @jpedroschmitz, @JerryGoyal, @bowen31337, @phillip055, @balazsorban44, @chuabingquan, @youhosi, @andresz1, @bell-steven, @areai51, @Wssn, @ndom91, @anthonyshort, @zxzl, @jbowes, @IamLizu, @PascalPixel, @ralphilius, @ysun62, @muslax, @elsigh, @AsherFoster, @botv, @tomdohnal, @christianalfoni, @tomasztunik, @gsimone, @illuminist, @jplew, @OskarKaminski, @RickyAbell, @steph-query, @ericgoe, @MalvinJay, @cristianbote, @Ashikpaul, @jensmeindertsma, @amorriscode, @abhik-b, @awareness481, @LukasPolak, @arvigeus, @romMidnight, @jackyef, @drumm2k, @kuldeepkeshwar, @bogy0, @Belco90, @wawjr3d, @tanmaylaud, @SarKurd, @kevinsproles, @dstotijn, @styfle, @blackwright, @BrunoBernardino, @heyAyushh, @Necmttn, @TrySound, @obedparla, @NyashaNziramasanga, @tonyspiro, @kukicado, @ceorourke, @MehediH, @robintom, @karlhorky und @tcK1!