Nextra, dokumentacja z MDX na wtyczce do Next.js

Nextra, dokumentacja z MDX na wtyczce do Next.js

Nextra to wtyczka do Next.js, która zamienia pliki MDX w gotową stronę dokumentacji albo blog, a cały wygląd bierze z osobnego pakietu z motywem. Bieżąca wersja pakietów nextra, nextra-theme-docs i nextra-theme-blog to 4.6.1, opublikowana w rejestrze npm 4 grudnia 2025 roku, na licencji MIT.

Piąty model budowania dokumentacji

Narzędzia do dokumentacji różnią się nie listą funkcji, tylko tym, gdzie kończy się Twój projekt, a zaczyna cudzy. Docusaurus to osobny framework na Reakcie z własnym routingiem i własnym buildem. Starlight to motyw dla Astro, więc dokumentacja jest osobnym projektem Astro. Mintlify to platforma hostowana, w której silnik renderujący nie należy do Ciebie. Fumadocs to zestaw bibliotek dokładanych do istniejącej aplikacji Next.js.

Nextra jest piątym układem: wtyczką do Next.js sterowaną motywem. Owijasz konfigurację Next.js funkcją nextra(), wrzucasz jedną trasę typu catch-all, importujesz komponent Layout z pakietu motywu i dostajesz skończoną stronę. Aplikacja Next.js istnieje, ale jest w praktyce nośnikiem dla dokumentacji, a nie produktem, do którego dokumentację dokładasz.

Różnica wobec Fumadocsa jest subtelna, więc opiszę ją konkretnie. W Fumadocsie składasz stronę z komponentów: masz własne trasy, własne układy, a biblioteka daje Ci klocki. W Nextrze konfigurujesz: cały wygląd to jeden komponent Layout z motywu, przyjmujący około dwudziestu właściwości, a Ty ustawiasz je tak, jak ustawia się opcje, nie tak, jak składa się interfejs. Kiedy chcesz coś poza tym zestawem, nie dokładasz komponentu obok, tylko podmieniasz motyw albo piszesz własny.

Drugi rozstrzygający punkt to wymagania platformy, bo bywa, że decydują za Ciebie. Nextra 4.6.1 deklaruje zależności równorzędne next: ">=14", react: ">=18" i react-dom: ">=18", a pole engines żąda Node w wersji co najmniej 18. Fumadocs 16.15.0 deklaruje next: "16.x.x" i react: "^19.2.0". Jeśli Twoja aplikacja stoi na Next.js 14 albo 15 i nie masz budżetu na migrację, Fumadocs odpada na etapie instalacji, a Nextra się zainstaluje. W drugą stronę: luźny zakres >=14 jest deklaracją, nie macierzą testów. Zgodność z Next.js 16 weszła dopiero w 4.6.1, co widać we wpisie w dzienniku zmian, a motyw nextra-theme-docs ma w zależnościach deweloperskich next: "^16.0.7".

Warto mieć w głowie jeszcze jedno: w rodzinie Nextry motywy przypinają rdzeń dokładną wersją. nextra-theme-docs@4.6.1 i nextra-theme-blog@4.6.1 mają w zależnościach równorzędnych nextra: "4.6.1", bez zakresu. To samo robi Fumadocs, gdzie fumadocs-ui przypina fumadocs-core na 16.15.0. Sprawdziłem wszystkie trzy pakiety Nextry i nie znalazłem rozjazdu ani w licencji, ani w zakresach: wszędzie MIT, wszędzie ten sam zestaw peerów.

Wersje, licencja i cztery numery poza rejestrem

Licencja wypada wzorcowo i trzy źródła mówią to samo. W repozytorium na gałęzi main istnieje wyłącznie plik LICENSE, treść to MIT z notą „Copyright (c) 2020 Shu Ding”; warianty LICENSE.md, LICENSE.MD, LICENSE.txt, LICENCE i COPYING zwracają 404. Pole license w rejestrze npm ma wartość MIT dla wszystkich trzech pakietów. Opublikowane paczki zawierają plik package/LICENSE o tej samej treści i realny kod w katalogu dist, więc deklaracja pokrywa się z zawartością. Pakiet nextra dokłada drugi plik, license.txt, i to nie jest sprzeczność: to MIT z notą „Copyright (c) 2019-PRESENT Vjacheslav Trushkin”, czyli nota autora Iconify dla wbudowanego pliku dist/iconify.js o rozmiarze 51 312 bajtów.

Rozmiary paczek: nextra po rozpakowaniu to 403 613 bajtów w 291 plikach i 39 zależności bezpośrednich, nextra-theme-docs to 299 142 bajty w 77 plikach i 7 zależności, nextra-theme-blog to 120 002 bajty w 30 plikach i 3 zależności. Sam arkusz stylów motywu docs waży 90 411 bajtów przed kompresją, motywu blog 97 591 bajtów.

Teraz rzecz, dla której warto przeczytać ten rozdział do końca. Wersja 4.6.1 wyszła 4 grudnia 2025 roku, czyli około ośmiu i pół miesiąca przed datą tego tekstu. Wcześniejszy rytm był zupełnie inny: 4.3.0 wyszło 28 lipca 2025, 4.4.0 dnia 22 sierpnia, 4.5.0 dnia 21 września, 4.5.1 dnia 27 września, 4.6.0 dnia 2 października. To mniej więcej jedno wydanie na miesiąc, więc obecna przerwa nie jest naturalnym tempem tego projektu, tylko wyraźnym spowolnieniem.

Spowolnienie nie oznacza jednak porzucenia i tu robi się ciekawie. Plik package.json na gałęzi main podaje wersję 4.6.5, zarówno dla nextra, jak i dla nextra-theme-docs. Dziennik zmian na main zawiera wpisy dla 4.6.2, 4.6.3, 4.6.4 i 4.6.5. W rejestrze npm najwyższym numerem jest 4.6.1. Cztery podbicia wersji zostały scalone i nigdy nie zostały opublikowane.

Co konkretnie w nich siedzi:

• 4.6.2 naprawia wyszukiwarkę Pagefind przy ustawionym basePath w konfiguracji Next.js. Adres bazowy indeksu był zapisany na sztywno jako '/' zamiast przechodzić przez addBasePath('/'), więc wdrożenie pod ścieżką w rodzaju /docs traciło wyszukiwanie.
• 4.6.3 i 4.6.4 nie mają własnych wpisów, zostały podbite jako pakiety zależne.
• 4.6.5 naprawia wyznaczanie GIT_ROOT dla drzew roboczych Gita. Wywołanie repository.path() wskazywało wewnątrz .git/worktrees/, przez co każde pobranie daty modyfikacji pliku przechodziło całą historię z nieistniejącej ścieżki. Wpis podaje pomiar: strona o 110 plikach budowała się około 176 sekund zamiast około 1,8 sekundy. Poprawka używa repository.workdir().

Kanał wydań też o czymś mówi. Ostatni commit na main pochodzi z 23 czerwca 2026 roku, czyli sprzed około dwóch miesięcy, i dodaje wpis do dokumentacji o integracji z Typesense. Dziewiętnaście najnowszych commitów rozkłada się między 3 października 2025 a 23 czerwca 2026, co daje mniej więcej dwa commity na miesiąc. Wśród nich jest jeden szczególnie wymowny, z 2 czerwca 2026: przełączenie publikacji do npm na Trusted Publishing przez OIDC. Wygląda to na próbę naprawy potoku wydawniczego, ale do dziś nic po niej nie zostało opublikowane.

W rejestrze nie wisi ani jedna wersja oznaczona jako wycofana; sprawdziłem wszystkie 364 wersje pakietu nextra. Znaczniki przedpremierowe są, ale żaden nie wyprzedza wydania stabilnego: alpha wskazuje na 4.3.0-alpha.31 z 10 lipca 2025, czyli sprzed samego 4.3.0, rc na 4.0.0-rc.0, beta na 2.0.0-beta.45, canary na 3.1.0-canary.1. Jest też pojedyncze 5.0.0-alpha.24 z 19 czerwca 2025, do którego nie prowadzi żaden znacznik i po którym nie ukazało się nic z linii 5.0.

Wniosek stawiam wprost: projekt nie jest martwy, bo commity idą przez cały 2026 rok, ale wydania stanęły, a naprawione błędy leżą w repozytorium poza zasięgiem npm install. Jeśli wybierasz Nextrę dziś, wybierasz stan z grudnia 2025 roku.

Konfiguracja: wtyczka, motyw i jedna trasa

Instalacja to trzy rzeczy: aplikacja Next.js, wtyczka z motywem i osobno indekser wyszukiwarki.

# aplikacja, wtyczka i motyw
npm i next react react-dom nextra nextra-theme-docs

# indekser wyszukiwarki to osobna zależność deweloperska
npm i -D pagefind

# build, a po nim indeksowanie zbudowanego HTML-a
npm run build
npx pagefind --site .next/server/app --output-path public/_pagefind

Konfiguracja wtyczki idzie do next.config.mjs. Funkcja nextra() przyjmuje obiekt NextraConfig i zwraca funkcję owijającą zwykłą konfigurację Next.js. Poniżej opcje wzięte ze schematu w opublikowanej paczce 4.6.1, nie z pamięci.

import nextra from 'nextra'

const withNextra = nextra({
  search: { codeblocks: false },
  staticImage: true,
  readingTime: true,
  defaultShowCopyCode: true,
  codeHighlight: true,
  contentDirBasePath: '/docs',
  whiteListTagsStyling: ['figure', 'figcaption'],
  mdxOptions: {
    format: 'detect',
    rehypePrettyCodeOptions: {}
  }
})

export default withNextra({
  reactStrictMode: true
})

Kilka z tych pól łatwo źle odczytać. staticImage i codeHighlight są domyślnie włączone. search ma domyślnie wartość { codeblocks: false }, więc bloki kodu nie trafiają do indeksu. whiteListTagsStyling rozszerza listę znaczników HTML podmienianych komponentami z pliku mdx-components.js; domyślnie Nextra podmienia tylko <details> i <summary>. contentDirBasePath przenosi katalog content pod wskazany prefiks zamiast pod korzeń. Jest też unstable_shouldAddLocaleToLinks, z przedrostkiem, który sam mówi, jak go traktować.

Cały wygląd konfiguruje się jednym komponentem. Nazwy właściwości poniżej pochodzą z typu LayoutProps w paczce nextra-theme-docs@4.6.1.

import { Footer, Layout, Navbar } from 'nextra-theme-docs'
import { Head } from 'nextra/components'
import { getPageMap } from 'nextra/page-map'
import 'nextra-theme-docs/style.css'

export default async function RootLayout({ children }) {
  return (
    <html lang="pl" dir="ltr" suppressHydrationWarning>
      <Head />
      <body>
        <Layout
          pageMap={await getPageMap()}
          navbar={<Navbar logo={<b>Dokumentacja</b>} />}
          footer={<Footer>MIT {new Date().getFullYear()}</Footer>}
          docsRepositoryBase="https://github.com/acme/docs/tree/main"
          copyPageButton
          darkMode
          sidebar={{ autoCollapse: true, defaultMenuCollapseLevel: 1, toggleButton: true }}
          toc={{ float: true, backToTop: 'Do góry', title: 'Na tej stronie' }}
          navigation={{ next: true, prev: true }}
          feedback={{ content: 'Pytania?', labels: 'feedback' }}
          themeSwitch={{ dark: 'Ciemny', light: 'Jasny', system: 'Systemowy' }}
        >
          {children}
        </Layout>
      </body>
    </html>
  )
}

Treść wpina się jedną trasą catch-all. Funkcja importPage zwraca obiekt z polami default, toc i metadata, a generateStaticParamsFor przyjmuje nazwę segmentu i opcjonalnie nazwę segmentu języka.

import { generateStaticParamsFor, importPage } from 'nextra/pages'
import { useMDXComponents as getMDXComponents } from '../../mdx-components'

export const generateStaticParams = generateStaticParamsFor('mdxPath')

export async function generateMetadata(props) {
  const params = await props.params
  const { metadata } = await importPage(params.mdxPath)
  return metadata
}

const Wrapper = getMDXComponents().wrapper

export default async function Page(props) {
  const params = await props.params
  const { default: MDXContent, toc, metadata } = await importPage(params.mdxPath)

  return (
    <Wrapper toc={toc} metadata={metadata}>
      <MDXContent {...props} params={params} />
    </Wrapper>
  )
}

Nawigację boczną i górną opisują pliki _meta, leżące obok treści. Schemat w paczce dopuszcza pięć kształtów wartości: sam tytuł, obiekt pozycji, odnośnik, separator i menu.

import type { MetaRecord } from 'nextra'

export default {
  index: 'Wprowadzenie',
  guide: { type: 'doc', title: 'Przewodnik' },
  api: { type: 'page', title: 'API', theme: { layout: 'full', toc: false } },
  changelog: { display: 'hidden' },
  'sep-1': { type: 'separator', title: 'Materiały' },
  github: { title: 'Repozytorium', href: 'https://github.com/acme/docs' },
  versions: {
    type: 'menu',
    title: 'Wersje',
    items: {
      v3: { title: 'Dokumentacja v3', href: 'https://v3.example.com' }
    }
  }
} satisfies MetaRecord

Pole display przyjmuje normal, hidden albo children, przy czym ostatnia wartość ukrywa sam katalog, zostawiając jego zawartość w drzewie. Pole theme obsługuje layout o wartości default albo full, oraz przełączniki navbar, pagination, sidebar, timestamp, toc i typesetting.

Motywy: dwa oficjalne i co dalej

Oficjalnych motywów są dokładnie dwa: nextra-theme-docs i nextra-theme-blog. Oba są na 4.6.1, oba wyszły tego samego dnia co rdzeń i oba przypinają go dokładną wersją, więc poruszają się w jednym takcie. Utrzymywane są tak samo dobrze albo tak samo słabo jak sam rdzeń, bo pochodzą z tego samego repozytorium i tego samego procesu wydawniczego.

Motyw docs daje pasek górny, wyszukiwarkę, nawigację boczną i spis treści strony. Eksportuje Layout, Navbar, Footer, LastUpdated, LocaleSwitch, NotFoundPage, ThemeSwitch, Link oraz haki useConfig, useMenu, useThemeConfig i useTheme. Motyw blog jest znacznie mniejszy: Layout, Navbar, Footer, PostCard, ThemeSwitch, Comments w oparciu o Cusdis i typ BlogMetadata. Trzy zależności i 30 plików, więc oczekiwania warto skalibrować.

Poza motywami rdzeń dostarcza komponenty przez nextra/components: Banner, Bleed, Button, Callout, Cards, Collapse, FileTree, Head, ImageZoom, Playground, Search, Select, Steps, Tabs, Popup, SkipNavContent, Mermaid, MathJax i MathJaxContext. Te działają niezależnie od tego, który motyw wybierzesz.

Ekosystem motywów spoza projektu wygląda blado. Wyszukiwanie frazy „nextra-theme” w rejestrze npm zwraca w większości rozgałęzienia motywu docs, których ostatnie publikacje mieszczą się między 2021 a 2024 rokiem. Kilka jest świeższych, na przykład nextra-theme-docs-neovate z numerem 4.6.4 z 6 stycznia 2026 roku, czyli numerem, który pod oficjalną nazwą nigdy się nie ukazał. To dobrze pokazuje, gdzie stoi ta gałąź ekosystemu: kto potrzebuje poprawek z gałęzi głównej, ten wypuszcza własne rozgałęzienie.

Kiedy potrzebujesz czegoś poza dwoma motywami, masz dwie drogi. Można nadpisać style, bo motyw jest zwykłym arkuszem CSS i zwykłymi komponentami Reacta. Można też napisać własny motyw, i to nie jest ścieżka zamknięta: rdzeń eksportuje getPageMap, normalizePages, importPage, evaluate, compileMdx i useMDXComponents, czyli komplet, z którego oficjalne motywy są zbudowane. Motyw w Nextrze to po prostu komponent przyjmujący pageMap. Koszt jest jednak realny, bo przejmujesz utrzymanie całego układu strony.

Wyszukiwarka Pagefind i jej rachunek

Nextra 4 używa Pagefind, tej samej biblioteki co Starlight, ale w innym trybie. Pagefind nie jest zależnością pakietu nextra. Sprawdziłem listę 39 zależności bezpośrednich i nie ma go tam. Instalujesz go sam jako zależność deweloperską i sam dopisujesz krok postbuild, bo Pagefind indeksuje zbudowane pliki .html, a nie źródła .md.

Opcja search w NextraConfig nie uruchamia indeksera i to jest najczęstsze nieporozumienie. Robi dokładnie dwie rzeczy: ustawia atrybut data-pagefind-body na elemencie <main> oraz, przy codeblocks: false, dokłada data-pagefind-ignore="all" do wszystkich elementów <pre>. Reszta należy do Ciebie.

Po stronie przeglądarki komponent Search importuje dynamicznie /_pagefind/pagefind.js przez addBasePath, z komentarzem webpackIgnore, dopiero po tym, jak pole wyszukiwania dostanie fokus. Indeks nie obciąża więc pierwszego renderu.

Zmierzyłem stały koszt na stronie nextra.site, która jest zbudowana Nextrą; plik pagefind-entry.json podaje tam Pagefind w wersji 1.3.0 i 76 stron w języku angielskim. Wyniki: pagefind.js waży 32 912 bajtów bez kompresji i 9 885 bajtów po gzipie, wasm.en.pagefind waży 70 873 bajty i przy żądaniu z gzipem zwraca 70 916 bajtów, czyli praktycznie się nie kompresuje, a plik metadanych pf_meta ma 653 bajty. Suma bez kompresji to 104 438 bajtów, a po drucie około 81 454 bajtów.

To około 81 kB przy pierwszym otwarciu wyszukiwarki, plus fragmenty indeksu dociągane osobno przy zapytaniach. W tekście o Starlightcie ta sama biblioteka wypadła powyżej 250 kB i różnica nie znaczy, że Nextra jest lżejsza: liczone jest co innego. Tutaj policzyłem trzy stałe pliki i pominąłem fragmenty indeksu, a te rosną wraz z korpusem. Przy stronie o kilku tysiącach podstron rachunek będzie inny i trzeba go zmierzyć u siebie.

Największa niedogodność jest inna niż rozmiar. Wyszukiwarka nie działa w next dev, bo indeksuje HTML powstały w buildzie. Nextra pokazuje w tym miejscu komunikat mówiący, żeby uruchomić next build, a potem zrestartować next dev. To znośne, ale trzeba o tym wiedzieć, zanim spędzi się godzinę na szukaniu błędu, którego nie ma.

Czego w rdzeniu nie ma

Wersjonowania dokumentacji Nextra nie ma. Sprawdziłem to zamiast założyć: w powierzchni publicznej pakietów nextra, nextra/page-map, nextra/pages i nextra/components nie ma niczego, co obsługiwałoby równoległe linie wersji, a sam projekt rozwiązuje to u siebie tak, że hostuje dokumentację v2 i v3 jako osobne wdrożenia i podlinkowuje je wpisem type: 'menu' w _meta. Jeśli oczekujesz mechanizmu z rdzenia Docusaurusa, gdzie zamrożone wersje są funkcją frameworka, w Nextrze będziesz to budować sam.

Druga dziura dotyczy Turbopacka. Z flagą --turbopack opcje loadera muszą być serializowalne do JSON-a, więc nie przekażesz własnych remarkPlugins, rehypePlugins ani recmaPlugins, bo to funkcje. Dokumentacja podaje komunikat, który wtedy zobaczysz: Error: loader nextra/loader for match "./{src/app,app}/**/page.{md,mdx}" does not have serializable options. Ta sama strona twierdzi, że Turbopack nie obsługuje next build, ale ma stempel „Last updated on October 3, 2025”, czyli pochodzi sprzed Next.js 16; to zdanie traktuj jako nieaktualne i sprawdź w dokumentacji Next.js, zanim się na nim oprzesz.

Trzecia rzecz to brak dostawcy i cennika, co jest zaletą i wadą naraz. Nextra jest w całości na MIT, nie ma planów płatnych ani wariantu komercyjnego, więc jedyny koszt to hosting aplikacji Next.js. Jednocześnie nie ma umowy wsparcia, którą można wyegzekwować, a widać na przykładzie ostatnich ośmiu miesięcy, co to znaczy w praktyce.

Nextra wobec Fumadocsa, Docusaurusa, Starlighta i Mintlify

Czytelna reguła wyboru wygląda tak. Jeśli dokumentacja jest całym projektem, a Ty chcesz skończony wygląd z pliku konfiguracyjnego i akceptujesz, że stoi na Next.js, bierz Nextrę. Jeśli dokumentacja ma być częścią istniejącej aplikacji produktowej i musi wtopić się w Twój system projektowy, bierz Fumadocsa, o ile stać Cię na Next.js 16. Jeśli nie chcesz mieć Next.js w ogóle, zostaje Docusaurus albo Starlight. Jeśli nie chcesz utrzymywać niczego, zostaje Mintlify wraz z jego cennikiem i zamkniętym silnikiem.

Do tego dokładam pytanie o tempo. Fumadocs wydaje często i wymusza wysokie wersje zależności, więc płacisz ciągłymi aktualizacjami. Nextra od ośmiu i pół miesiąca nie wydała nic, więc płacisz brakiem poprawek. To dwa różne rodzaje kosztu i dwa różne rodzaje ryzyka, i wybór między nimi zależy bardziej od tego, ile masz czasu na utrzymanie, niż od listy funkcji.

Typowe błędy

Oczekiwanie, że wyszukiwarka zadziała w trybie deweloperskim. Nie zadziała, bo Pagefind indeksuje zbudowany HTML. Trzeba uruchomić next build, potem krok postbuild, a dopiero potem wrócić do next dev.

Pominięcie kroku postbuild albo zła ścieżka. Dla zwykłego buildu serwerowego jest to pagefind --site .next/server/app --output-path public/_pagefind, a dla eksportu statycznego ten sam --site, ale --output-path out/_pagefind. Pomylenie katalogu wyjściowego daje pustą wyszukiwarkę bez żadnego błędu w konsoli.

Ustawienie basePath w Next.js na wersji 4.6.1. Indeks nie wczyta się spod prefiksu, bo adres bazowy jest zapisany na sztywno. Poprawka istnieje w repozytorium jako 4.6.2, ale nie ma jej w rejestrze npm. Realne wyjścia to wdrożenie w korzeniu domeny albo łatka na zainstalowanej paczce.

Przekazywanie własnych wtyczek remark lub rehype przy next dev --turbopack. Opcje loadera muszą być serializowalne, więc funkcje przelecą z błędem. Dla tej konfiguracji zostaje Webpack.

Mieszanie wersji rdzenia i motywu. Zależność równorzędna jest przypięta dokładną wartością, więc menedżer pakietów w trybie ścisłym odmówi instalacji nextra@4.6.1 z motywem w innej wersji. Te dwa pakiety podnosi się razem.

Czytanie dokumentacji z gałęzi głównej i zakładanie, że poprawka jest w paczce. To dziś najkosztowniejsza pomyłka przy tym projekcie. Dziennik zmian opisuje 4.6.5, a npm install da Ci 4.6.1.

Liczenie na wersjonowanie dokumentacji z pudełka. Trzeba je zbudować samodzielnie, najczęściej jako osobne wdrożenia podlinkowane menu w _meta.

FAQ

Czy Nextra jest porzucona?

Nie w sensie martwego repozytorium, ale wydania stanęły. Ostatnia publikacja w npm to 4.6.1 z 4 grudnia 2025 roku, a ostatni commit na gałęzi głównej pochodzi z 23 czerwca 2026. Między tymi datami scalono cztery podbicia wersji, do 4.6.5 włącznie, i żadne nie trafiło do rejestru. Jest też commit z 2 czerwca 2026 przełączający publikację na Trusted Publishing, co wygląda na naprawianie potoku wydawniczego. Praktyczny wniosek: instalując Nextrę, dostajesz stan z grudnia 2025.

Nextra czy Fumadocs, jeśli i tak używam Next.js?

Rozstrzyga to, czym jest dokumentacja w Twoim projekcie. Nextra sprawdza się, gdy dokumentacja jest całym serwisem i wystarczy Ci wygląd, który daje motyw ustawiany właściwościami komponentu Layout. Fumadocs sprawdza się, gdy dokumentacja to sekcja istniejącej aplikacji i musi używać Twoich komponentów. Drugi czynnik jest twardy: Fumadocs 16.15.0 wymaga Next.js 16 i Reacta 19.2, Nextra 4.6.1 deklaruje next >=14 i react >=18.

Ile realnie kosztuje wyszukiwarka?

Na stronie nextra.site, przy 76 stronach i Pagefind 1.3.0, stały narzut to 32 912 bajtów pliku pagefind.js (9 885 po gzipie), 70 873 bajty pliku WebAssembly, który się nie kompresuje, i 653 bajty metadanych, czyli około 81 kB po drucie. Wczytuje się dopiero po kliknięciu w pole wyszukiwania, więc nie wpływa na pierwszy render. Do tego dochodzą fragmenty indeksu pobierane przy zapytaniach, rosnące wraz z liczbą stron.

Czy Nextra obsługuje wersjonowanie dokumentacji?

Nie ma tego w rdzeniu. Ani API pakietu nextra, ani motywy nie mają mechanizmu równoległych linii wersji. Sam projekt hostuje dokumentację v2 i v3 jako osobne wdrożenia i wystawia je jako pozycję type: 'menu' w pliku _meta. Jeśli wersjonowanie jest wymogiem, Docusaurus ma je w rdzeniu i to jest sensowniejszy wybór.

Czy da się użyć Nextry bez oficjalnego motywu?

Da się. Rdzeń eksportuje getPageMap, normalizePages, importPage, compileMdx, evaluate i useMDXComponents, a motyw to komponent przyjmujący pageMap, więc własny układ jest wykonalny i oficjalne motywy powstały z tych samych klocków. Kosztem jest utrzymanie całej warstwy widoku po Twojej stronie, łącznie z nawigacją, spisem treści i trybem ciemnym.

Czy Nextra działa z Next.js 16 i z TypeScriptem?

Zgodność z Next.js 16 weszła w 4.6.1, co potwierdza wpis w dzienniku zmian, a motyw docs testuje się przeciwko next ^16.0.7. Typy są dostarczane w paczkach, _meta.ts opisuje typ MetaRecord, a konfiguracja wtyczki typ NextraConfig, więc pisanie w TypeScripcie nie wymaga dodatkowych pakietów. Źródła: repozytorium projektu, przewodnik po wyszukiwarce i dokumentacja Pagefind.