BackZurück zum Blog

Next.js 15 RC 2

Die zweite Release Candidate (RC) von Next.js 15 ist jetzt verfügbar. Diese Version ermöglicht es Ihnen, die neuesten Funktionen vor der bevorstehenden stabilen Veröffentlichung zu testen.

Nach der Ankündigung des ersten Next.js 15 Release Candidates im Mai haben wir basierend auf Ihrem Feedback eine zweite Release Candidate vorbereitet. Hier ist, woran wir gearbeitet haben:

Testen Sie den Next.js 15 Release Candidate (RC2) heute:

# Verwenden Sie die neue automatisierte Upgrade-CLI
npx @next/codemod@canary upgrade rc
 
# ...oder führen Sie ein manuelles Upgrade durch
npm install next@rc react@rc react-dom@rc

Hinweis: Dieser Release Candidate enthält alle Änderungen aus dem vorherigen RC.

Einfache Upgrades mit der codemod CLI

Wir liefern mit jedem größeren Next.js-Release Codemods (automatisierte Code-Transformationen) mit, um das Upgrade von Breaking Changes zu automatisieren.

Um Upgrades noch einfacher zu machen, haben wir eine verbesserte codemod CLI veröffentlicht:

npx @next/codemod@canary upgrade rc

Dieses Tool hilft Ihnen, Ihre Codebasis auf die neuesten stabilen oder Vorabversionen zu aktualisieren. Die CLI aktualisiert Ihre Abhängigkeiten, zeigt verfügbare Codemods an und führt Sie durch deren Anwendung. Der angegebene Dist-Tag in der Befehlszeile (@rc, @canary, etc.) bestimmt die Version, auf die upgegradet wird.

Erfahren Sie mehr über Next.js Codemods.

Turbopack für die Entwicklung

Turbopack für die lokale Entwicklung wird im allgemeinen Release von Next.js 15 stabil sein, bleibt aber optional. Sie können es heute testen, indem Sie folgenden Befehl ausführen:

next dev --turbo

Dank der tausenden Entwickler, die während der Turbopack-Beta- und Release-Candidate-Phasen an Tests teilgenommen, Probleme gemeldet und Fixes verifiziert haben, haben wir 54 GitHub-Issues seit dem ersten Next.js 15 Release Candidate behoben. Neben dieser Community-Beteiligung haben unsere internen Tests auf vercel.com, v0.dev und nextjs.org zahlreiche weitere Verbesserungen identifiziert.

In den letzten drei Monaten haben wir uns auf die Optimierung der Kaltkompilierungsleistung konzentriert. Im Vergleich zum vorherigen Release haben wir folgende Verbesserungen festgestellt:

  • 25–35% geringerer Speicherverbrauch.
  • 30–50% schnellere Kompilierung für große Seiten mit tausenden Modulen.

Wir werden diese Bereiche in zukünftigen Releases weiter optimieren.

Aktuell macht das Turbopack-Team große Fortschritte bei persistentem Caching, Speicherverbrauchsreduzierung und Turbopack für next build—mit 96% der bestandenen Tests.

Hinweis: Sehen Sie sich alle unterstützten und nicht unterstützten Funktionen von Turbopack an.

Asynchrone Request-APIs (Breaking Change)

Beim traditionellen Server-Side Rendering wartet der Server auf eine Anfrage, bevor er Inhalte rendert. Allerdings hängen nicht alle Komponenten von anfragespezifischen Daten ab, daher ist es unnötig, auf die Anfrage zu warten, um sie zu rendern. Idealerweise würde der Server so viel wie möglich vorbereiten, bevor eine Anfrage eintrifft. Um dies zu ermöglichen und die Grundlage für zukünftige Optimierungen zu schaffen, müssen wir wissen, wann auf die Anfrage gewartet werden muss.

Daher werden wir APIs, die auf anfragespezifischen Daten basieren—wie headers, cookies, params und searchParams—auf asynchrone Operationen umstellen.

import { cookies } from 'next/headers';
 
export async function AdminPanel() {
  const cookieStore = await cookies();
  const token = cookieStore.get('token');
 
  // ...
}

Dies ist ein Breaking Change und betrifft die folgenden APIs:

  • cookies
  • headers
  • draftMode
  • params in layout.js, page.js, route.js, default.js, generateMetadata und generateViewport
  • searchParams in page.js

Für eine einfachere Migration können diese APIs vorübergehend synchron aufgerufen werden, zeigen aber Warnungen in Entwicklung und Produktion bis zur nächsten Hauptversion an. Ein Codemod steht zur Automatisierung der Migration zur Verfügung:

npx @next/codemod@canary next-async-request-api .

Für Fälle, in denen das Codemod Ihren Code nicht vollständig migrieren kann, lesen Sie bitte den Upgrade-Guide. Wir haben auch ein Beispiel bereitgestellt, wie Sie eine Next.js-Anwendung auf die neuen APIs migrieren können.

Verbesserte Sicherheit für Server-Aktionen

Server-Aktionen sind serverseitige Funktionen, die vom Client aufgerufen werden können. Sie werden definiert, indem die Direktive 'use server' am Anfang einer Datei hinzugefügt und eine asynchrone Funktion exportiert wird.

Auch wenn eine Server-Aktion oder Hilfsfunktion nicht anderswo in Ihrem Code importiert wird, ist sie dennoch ein öffentlich zugänglicher HTTP-Endpunkt. Während dieses Verhalten technisch korrekt ist, kann es zu unbeabsichtigter Freigabe solcher Funktionen führen.

Um die Sicherheit zu verbessern, haben wir folgende Erweiterungen eingeführt:

  • Dead-Code-Eliminierung: Unbenutzte Server-Aktionen werden nicht in das clientseitige JavaScript-Bundle aufgenommen, was die Bundle-Größe reduziert und die Leistung verbessert.
  • Sichere Aktions-IDs: Next.js erstellt jetzt nicht erratbare, nicht-deterministische IDs, die es dem Client ermöglichen, auf die Server-Aktion zu verweisen und sie aufzurufen. Diese IDs werden zwischen Builds periodisch neu berechnet, um die Sicherheit zu erhöhen.
// app/actions.js
'use server';
 
// Diese Aktion **wird** in unserer Anwendung verwendet, daher erstellt Next.js
// eine sichere ID, die es dem Client ermöglicht, auf die Server-Aktion
// zu verweisen und sie aufzurufen.
export async function updateUserAction(formData) {}
 
// Diese Aktion **wird nicht** in unserer Anwendung verwendet, daher entfernt Next.js
// diesen Code automatisch während `next build`
// und erstellt keinen öffentlichen Endpunkt.
export async function deleteUserAction(formData) {}

Sie sollten Server-Aktionen weiterhin als öffentliche HTTP-Endpunkte behandeln. Erfahren Sie mehr über das Sichern von Server-Aktionen.

Statischer Routen-Indikator

Next.js zeigt jetzt während der Entwicklung einen statischen Routen-Indikator an, um Ihnen zu helfen, statische oder dynamische Routen zu identifizieren. Dieser visuelle Hinweis erleichtert die Leistungsoptimierung, indem Sie verstehen, wie Ihre Seiten gerendert werden.

Sie können auch die next build-Ausgabe verwenden, um die Rendering-Strategie für alle Routen anzuzeigen.

Dieses Update ist Teil unserer laufenden Bemühungen, die Beobachtbarkeit in Next.js zu verbessern, um Entwicklern das Überwachen, Debuggen und Optimieren ihrer Anwendungen zu erleichtern. Wir arbeiten auch an dedizierten Entwickler-Tools, mit weiteren Details in Kürze.

Erfahren Sie mehr über den statischen Routen-Indikator, der deaktiviert werden kann.

<Form>-Komponente

Die neue <Form>-Komponente erweitert das HTML-<form>-Element mit Prefetching, clientseitiger Navigation und progressiver Verbesserung.

Sie ist nützlich für Formulare, die zu einer neuen Seite navigieren, wie z.B. ein Suchformular, das zu einer Ergebnisseite führt.

import Form from 'next/form';
 
export default function Page() {
  return (
    <Form action="/search">
      <input name="query" />
      <button type="submit">Submit</button>
    </Form>
  );
}

Die <Form>-Komponente bietet:

  • Prefetching: Wenn das Formular im Viewport ist, werden das Layout und die Lade-UI vorab geladen, was die Navigation beschleunigt.
  • Clientseitige Navigation: Beim Absenden werden gemeinsame Layouts und der clientseitige Zustand erhalten.
  • Progressive Verbesserung: Wenn JavaScript noch nicht geladen wurde, funktioniert das Formular dennoch über eine vollständige Seiten-Navigation.

Bisher erforderte die Implementierung dieser Features viel manuellen Boilerplate-Code. Zum Beispiel:

Beispiel

// Hinweis: Dies ist zur Demonstration gekürzt.
// Nicht für Produktionscode empfohlen.
 
'use client'
 
import { useEffect } from 'react'
import { useRouter } from 'next/navigation'
 
export default function Form(props) {
  const action = props.action
  const router = useRouter()
 
  useEffect(() => {
    // wenn das Formular-Ziel eine URL ist, prefetch es
    if (typeof action === 'string') {
      router.prefetch(action)
    }
  }, [action, router])
 
  function onSubmit(event) {
    event.preventDefault()
 
    // alle Formularfelder erfassen und ein `router.push` mit den URL-kodierten Daten auslösen
    const formData = new FormData(event.currentTarget)
    const data = new URLSearchParams()
 
    for (const [name, value] of formData) {
      data.append(name, value as string)
    }
 
    router.push(`${action}?${data.toString()}`)
  }
 
  if (typeof action === 'string') {
    return <form onSubmit={onSubmit} {...props} />
  }
 
  return <form {...props} />
}

Erfahren Sie mehr über die <Form>-Komponente.

Unterstützung für next.config.ts

Next.js unterstützt jetzt den TypeScript-Dateityp next.config.ts und stellt einen NextConfig-Typ für Autovervollständigung und typsichere Optionen bereit:

import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  /* Konfigurationsoptionen hier */
};
 
export default nextConfig;

Erfahren Sie mehr über TypeScript-Unterstützung in Next.js.

instrumentation.js (Stabil)

Die instrumentation-Datei mit der register()-API ermöglicht es Benutzern, in den Next.js-Server-Lebenszyklus einzugreifen, um die Leistung zu überwachen, Fehlerquellen zu verfolgen und tiefgehende Integrationen mit Observability-Bibliotheken wie OpenTelemetry durchzuführen.

Diese Funktion ist jetzt stabil und die experimental.instrumentationHook-Konfigurationsoption kann entfernt werden.

Zusätzlich haben wir mit Sentry an der Gestaltung eines neuen onRequestError-Hooks zusammengearbeitet, der verwendet werden kann, um:

  • Wichtigen Kontext über alle auf dem Server geworfenen Fehler zu erfassen, einschließlich:
    • Router: Pages Router oder App Router
    • Server-Kontext: Server-Komponente, Server-Aktion, Route-Handler oder Middleware
  • Die Fehler an Ihren bevorzugten Observability-Provider zu melden.
export async function onRequestError(err, request, context) {
  await fetch('https://...', {
    method: 'POST',
    body: JSON.stringify({ message: err.message, request, context }),
    headers: { 'Content-Type': 'application/json' },
  });
}
 
export async function register() {
  // Initialisieren Sie das SDK Ihres bevorzugten Observability-Providers
}

Erfahren Sie mehr über die onRequestError-Funktion.

Entwicklungs- und Build-Verbesserungen

Server-Komponenten HMR

Während der Entwicklung werden Server-Komponenten neu ausgeführt, wenn sie gespeichert werden. Das bedeutet, dass alle fetch-Anfragen an Ihre API-Endpunkte oder Drittanbieter-Dienste ebenfalls aufgerufen werden.

Um die lokale Entwicklungsleistung zu verbessern und potenzielle Kosten für abgerechnete API-Aufrufe zu reduzieren, stellen wir jetzt sicher, dass Hot Module Replacement (HMR) fetch-Antworten von vorherigen Renderings wiederverwenden kann.

Erfahren Sie mehr über den Server-Komponenten HMR Cache.

Schnellere statische Generierung für den App Router

Wir haben die statische Generierung optimiert, um Build-Zeiten zu verbessern, insbesondere für Seiten mit langsamen Netzwerkanfragen.

Bisher hat unser statischer Optimierungsprozess Seiten zweimal gerendert—einmal, um Daten für die clientseitige Navigation zu generieren, und ein zweites Mal, um das HTML für den ersten Seitenbesuch zu rendern. Jetzt verwenden wir das erste Rendering wieder, eliminieren den zweiten Durchlauf und reduzieren so die Arbeitslast und die Build-Zeiten.

Zusätzlich teilen sich statische Generierungs-Worker jetzt den fetch-Cache über Seiten hinweg. Wenn ein fetch-Aufruf das Caching nicht deaktiviert, werden seine Ergebnisse von anderen Seiten, die vom selben Worker bearbeitet werden, wiederverwendet. Dies reduziert die Anzahl der Anfragen für dieselben Daten.

Erweiterte Steuerung der statischen Generierung (Experimentell)

Wir haben experimentelle Unterstützung für eine bessere Kontrolle über den Prozess der statischen Generierung für fortgeschrittene Anwendungsfälle hinzugefügt, die von einer größeren Steuerung profitieren würden.

Wir empfehlen, bei den aktuellen Standardeinstellungen zu bleiben, es sei denn, Sie haben spezifische Anforderungen, da diese Optionen zu erhöhtem Ressourcenverbrauch und potenziellen Speicherüberlastungsfehlern aufgrund höherer Parallelität führen können.

const nextConfig = {
  experimental: {
	  // wie oft Next.js fehlgeschlagene Seiten-Generierungsversuche wiederholt
	  // bevor der Build fehlschlägt
    staticGenerationRetryCount: 1
    // wie viele Seiten pro Worker verarbeitet werden
    staticGenerationMaxConcurrency: 8
    // die minimale Anzahl von Seiten, bevor ein neuer Export-Worker gestartet wird
    staticGenerationMinPagesPerWorker: 25
  },
}
 
export default nextConfig;

Erfahren Sie mehr über die Optionen für statische Generierung.

Verbesserungen für Self-Hosting

Beim Self-Hosting von Anwendungen benötigen Sie möglicherweise mehr Kontrolle über Cache-Control-Direktiven.

Ein häufiger Anwendungsfall ist die Steuerung des stale-while-revalidate-Zeitraums für ISR-Seiten. Wir haben zwei Verbesserungen implementiert:

  1. Sie können jetzt den expireTime-Wert in next.config konfigurieren. Dies war zuvor die Option experimental.swrDelta.
  2. Der Standardwert wurde auf ein Jahr aktualisiert, um sicherzustellen, dass die meisten CDNs die stale-while-revalidate-Semantik wie vorgesehen vollständig anwenden können.

Wir überschreiben außerdem keine benutzerdefinierten Cache-Control-Werte mehr mit unseren Standardwerten, was volle Kontrolle und Kompatibilität mit jeder CDN-Einrichtung ermöglicht.

Schließlich haben wir die Bildoptimierung beim Self-Hosting verbessert. Bisher wurde empfohlen, sharp für die Bildoptimierung auf Ihrem Next.js-Server zu installieren. Diese Empfehlung wurde manchmal übersehen. Mit Next.js 15 müssen Sie sharp nicht mehr manuell installieren – Next.js verwendet sharp automatisch bei Verwendung von next start oder im Standalone-Ausgabemodus.

Weitere Informationen finden Sie in unserem neuen Demo- und Tutorial-Video zum Self-Hosting von Next.js.

ESLint 9-Unterstützung

Next.js 15 führt auch Unterstützung für ESLint 9 ein, nachdem ESLint 8 am 5. Oktober 2024 das Ende seiner Lebensdauer erreicht hat.

Um einen reibungslosen Übergang zu gewährleisten, bleibt Next.js abwärtskompatibel, was bedeutet, dass Sie weiterhin entweder ESLint 8 oder 9 verwenden können.

Wenn Sie auf ESLint 9 aktualisieren und wir feststellen, dass Sie das neue Konfigurationsformat noch nicht übernommen haben, wendet Next.js automatisch den Ausweg ESLINT_USE_FLAT_CONFIG=false an, um die Migration zu erleichtern.

Darüber hinaus werden veraltete Optionen wie —ext und —ignore-path beim Ausführen von next lint entfernt. Bitte beachten Sie, dass ESLint diese älteren Konfigurationen in ESLint 10 nicht mehr zulassen wird, daher empfehlen wir, bald mit der Migration zu beginnen.

Weitere Details zu diesen Änderungen finden Sie im Migrationsleitfaden.

Als Teil dieses Updates haben wir auch eslint-plugin-react-hooks auf v5.0.0 aktualisiert, das neue Regeln für die Verwendung von React Hooks einführt. Sie können alle Änderungen im Changelog für [email protected] einsehen.

Weitere Änderungen

  • Alle zuvor im RC 1-Blogpost beschriebenen Änderungen
  • [Breaking] Wir haben das Exportieren von export const runtime = "experimental-edge" im App Router als veraltet markiert. Benutzer sollten jetzt auf export const runtime = "edge" umsteigen. Wir haben einen Codemod hinzugefügt, um dies durchzuführen (PR)
  • [Breaking] Der Aufruf von revalidateTag und revalidatePath während des Renderings führt jetzt zu einem Fehler (PR)
  • [Breaking] Die Dateien instrumentation.js und middleware.js verwenden jetzt die vendorierten React-Pakete (PR)
  • [Breaking] Die mindestens erforderliche Node.js-Version wurde auf 18.18.0 aktualisiert (PR)
  • [Breaking] next/dynamic: Die veraltete suspense-Eigenschaft wurde entfernt und wenn die Komponente im App Router verwendet wird, wird keine leere Suspense-Boundary mehr eingefügt (PR)
  • [Breaking] Beim Auflösen von Modulen in der Edge Runtime wird die worker-Modulbedingung nicht mehr angewendet (PR)
  • [Breaking] Die Verwendung der Option ssr: false mit next/dynamic in Server Components ist nicht mehr erlaubt (PR)
  • [Verbesserung] Die Optionen outputFileTracingRoot, outputFileTracingIncludes und outputFileTracingExcludes wurden von experimentell auf stabil hochgestuft (PR)
  • [Verbesserung] Vermeidung der Zusammenführung globaler CSS-Dateien mit CSS-Modul-Dateien tiefer in der Baumstruktur (PR)
  • [Verbesserung] Der Cache-Handler kann über die Umgebungsvariable NEXT_CACHE_HANDLER_PATH angegeben werden (PR)
  • [Verbesserung] Der Pages Router unterstützt jetzt sowohl React 18 als auch React 19 (PR)
  • [Verbesserung] Das Error Overlay zeigt jetzt eine Schaltfläche zum Kopieren der Node.js Inspector-URL an, wenn der Inspector aktiviert ist (PR)
  • [Verbesserung] Client-Prefetches im App Router verwenden jetzt das priority-Attribut (PR)
  • [Verbesserung] Next.js stellt jetzt eine unstable_rethrow-Funktion bereit, um interne Next.js-Fehler im App Router erneut auszulösen (PR)
  • [Verbesserung] unstable_after kann jetzt in statischen Seiten verwendet werden (PR)
  • [Verbesserung] Wenn eine next/dynamic-Komponente während SSR verwendet wird, wird der Chunk vorab geladen (PR)
  • [Verbesserung] Die Option esmExternals wird jetzt im App Router unterstützt (PR)
  • [Verbesserung] Die Option experimental.allowDevelopmentBuild kann verwendet werden, um NODE_ENV=development mit next build für Debugging-Zwecke zuzulassen (PR)
  • [Verbesserung] Die Server-Action-Transforms sind jetzt im Pages Router deaktiviert (PR)
  • [Verbesserung] Build-Worker verhindern jetzt, dass der Build hängen bleibt, wenn sie beendet werden (PR)
  • [Verbesserung] Bei einer Weiterleitung von einer Server-Action werden Revalidierungen jetzt korrekt angewendet (PR)
  • [Verbesserung] Dynamische Parameter werden jetzt korrekt für parallele Routen in der Edge Runtime verarbeitet (PR)
  • [Verbesserung] Statische Seiten berücksichtigen jetzt staleTime nach dem ersten Laden (PR)
  • [Verbesserung] vercel/og mit einer Speicherleck-Behebung aktualisiert (PR)
  • [Verbesserung] Patch-Zeiten aktualisiert, um die Verwendung von Paketen wie msw für API-Mocking zu ermöglichen (PR)

Mitwirkende

Next.js ist das Ergebnis der gemeinsamen Arbeit von über 3.000 einzelnen Entwicklern und unserem Core-Team bei Vercel. Diese Version wurde ermöglicht durch:

Ein riesiges Dankeschön an @huozhi, @shuding, @wyattjoh, @PaulAsjes, @mcnaveen, @timneutkens, @stipsan, @aktoriukas, @sirTangale, @greatvivek11, @sokra, @anatoliik-lyft, @wbinnssmith, @coltonehrman, @hungdoansy, @kxlow, @ztanner, @manovotny, @leerob, @ryota-murakami, @ijjk, @pnutmath, @feugy, @Jeffrey-Zutt, @wiesson, @eps1lon, @devjiwonchoi, @Ethan-Arrowood, @kenji-webdev, @domdomegg, @samcx, @Jaaneek, @evanwinter, @kdy1, @balazsorban44, @feedthejim, @ForsakenHarmony, @kwonoj, @delbaoliveira, @xiaohanyu, @dvoytenko, @bobaaaaa, @bgw, @gaspar09, @souporserious, @unflxw, @kiner-tang, @Ehren12, @EffectDoplera, @IAmKushagraSharma, @Auxdible, @sean-rallycry, @jeanmax1me, @unstubbable, @NilsJacobsen, @adiguno, @ryan-nauman, @zsh77, @KagamiChan, @steveluscher, @MehfoozurRehman, @vkryachko, @chentsulin, @samijaber, @begalinsaf, @FluxCapacitor2, @lukahartwig, @brianshano, @pavelglac, @styfle, @symant233, @HristovCodes, @karlhorky, @jonluca, @jonathan-ingram, @mknichel, @sopranopillow, @Gomah, @imddc, @notrab, @gabrielrolfsen, @remorses, @AbhiShake1, @agadzik, @rishabhpoddar, @rezamauliadi, @IncognitoTGT, @webtinax, @BunsDev, @nisabmohd, @z0n, @bennettdams, @joeshub, @n1ckoates, @srkirkland, @RiskyMH, @coopbri, @okoyecharles, @diogocapela, @dnhn, @typeofweb, @davidsa03, @imranolas, @lubieowoce, @maxhaomh, @mirasayon, @blvdmitry, @hwangstar156, @lforst, @emmerich, @christian-bromann, @Lsnsh, @datner, @hiro0218, @flybayer, @ianmacartney, @ypessoa, @ryohidaka, @icyJoseph, @Arinji2, @lovell, @nsams, @Nayeem-XTREME, @JamBalaya56562, @Arindam200, @gaojude, @qqww08, @todor0v, @tokkiyaa, @arlyon, @lorensr, @Juneezee, @Sayakie, @IGassmann, @bosconian-dynamics, @phryneas, @akazwz, @atik-persei, @shubh73, @alpedia0, @chogyejin, @notomo, @ArnoldVanN, @dhruv-kaushik, @kevva, @Kahitar, @anay-208, @boris-szl, @devnyxie, @LorisSigrist, @M-YasirGhaffar, @Lada496, @kippmr, @torresgol10, @pkiv, @Netail, @jontewks, @ArnaudFavier, @chrisjstott, @mratlamwala, @mayank1513, @karlkeefer, @kshehadeh, @Marukome0743, @a89529294, @anku255, @KeisukeNagakawa, @andrii-bodnar, @aldosch, @versecafe, @steadily-worked, @cfrank, @QiuranHu, @farsabbutt, @joostmeijles, @saltcod, @archanaagivale30, @crutchcorn, @crebelskydico, @Maaz-Ahmed007, @jophy-ye, @remcohaszing, @JoshuaKGoldberg, @creativoma, @GyoHeon, @SukkaW, @MaxLeiter, @neila-a, @stylessh, @Teddir, @ManuLpz4, @Julian-Louis, @syi0808, @mert-duzgun, @amannn, @MonstraG, @hamirmahal, @tariknh, @Kikobeats, @LichuAcu, @Kuboczoch, @himself65, @Sam-Phillemon9493, @Shruthireddy04, @Hemanshu-Upadhyay, @timfuhrmann, @controversial, @pathliving, @mischnic, @mauroaccornero, @NavidNourani, @allanchau, @ekremkenter, @yurivangeffen, @gnoff, @darthmaim, @gdborton, @Willem-Jaap, @KentoMoriwaki, @TrevorSayre, @marlier, @Luluno01, @xixixao, @domin-mnd, @niketchandivade, @N2D4, @kjugi, @luciancah, @mud-ali, @codeSTACKr, @luojiyin1987, @mehmetozguldev, @ronanru, @tknickman, @joelhooks, @khawajaJunaid, @rubyisrust, @abdull-haseeb, @bewinsnw, @housseindjirdeh, @li-jia-nan, @aralroca, @s-ekai, @ah100101, @jantimon, @jordienr, @iscekic, @Strift, @slimbde, @nauvalazhar, @HughHzyb, @guisehn, @wesbos, @OlyaPolya, @paarthmadan, @AhmedBaset, @dineshh-m, @avdeev, @Bhavya031, @MildTomato, @Bjornnyborg, @amikofalvy, @yosefbeder, @kjac, @woutvanderploeg, @Ocheretovich, @ProchaLu, @luismiramirez, @omahs, @theoludwig, @abhi12299, @sommeeeer, @lumirlumir, @royalfig, @iampoul, @molebox, @txxxxc, @zce, @mamuso, @kahlstrm, @vercel-release-bot, @zhawtof, @PapatMayuri, @PlagueFPS, @IDNK2203, @jericopulvera, @liby, @CannonLock, @timfish, @whatisagi, @none23, @haouvw, @Pyr33x, @SouthLink, @frydj, @CrutchTheClutch, @sleevezip, @r34son, @yunsii, @md-rejoyan-islam, @kartheesan05, @nattui, @KonkenBonken, @weicheng95, @brekk, @Francoscopic, @B33fb0n3, @ImDR, @nurullah, @hdodov, @ebCrypto, @soedirgo, @floriangosse, @Tim-Zj, @raeyoung-kim, @erwannbst, @DerTimonius, @hirotomoyamada, @Develliot, @chandanpasunoori, @vicb, @ankur-dwivedi, @kidonng, @baeharam, @AnaTofuZ, @coderfin, @xugetsu, @alessiomaffeis, @kutsan, @jordyfontoura, @sebmarkbage, @tranvanhieu01012002, @jlbovenzo, @Luk-z, @jaredhan418, @bangseongbeom, @penicillin0, @neoFinch, @DeepakBalaraman, @Manoj-M-S, @Unsleeping, @lonr, @Aerilym, @ytori, @acdlite, @actopas, @n-ii-ma, @adcichowski, @mobeigi, @JohnGemstone und @jjm2317 für ihre Hilfe!