Next.js: Wie kann man ändern, wo Next nach Seiten sucht?

AFAIK, das können Sie nicht. Sie können das Dateisystem-Routing über next.config.js deaktivieren .

Laut den Dokumenten gibt dir den Speicherort des Projekts an, also wäre der richtige Weg, es auf ./src :

const next = require('next')({
  dev,
  dir: './src'
})

Aber es wird nur in einer programmatischen API (mit einem benutzerdefinierten Server) verwendet und wirkt sich auch auf den mutmaßlichen Speicherort anderer Dateien aus (wie ich glaube, wie das Verzeichnis next.config.js und static ).

Keine Ahnung, was diese anderen Kommentare sagen, aber Sie können konfigurieren, welches Verzeichnis next.js über die Befehlszeile nach Seiten sucht:

$ next ./src
$ next dev ./src
$ next build ./src
$ next start ./src -p 8080

Sie können das Verzeichnis nicht ändern, und wir planen auch nicht, dies zu ändern. Bitte suchen Sie in Zukunft im Issue-Tracker nach einem Problem (einschließlich geschlossener Probleme), bevor Sie ein Problem veröffentlichen, da diese Frage schon einige Male aufgetreten ist .

@timneutkens ist nicht wie der Betreuer von moment.js, der die Optimierung für clientseitige Apps abgelehnt hat, was in vielen Projekten zu benutzerdefinierten Konfigurationen geführt hat, sogar in CRA.
Viele Projekt-Boilerplates haben einen src Ordner, in dem Dateien lagen.

Da dies derzeit das erste Ergebnis bei der Suche bei Google ist, wäre es vielleicht von Vorteil, die Gründe für diese Entscheidung

Wie von @brainkim angegeben, fügen Sie Ihre Paket-Json-Skripte mit ./src an. Was Sie vielleicht auch tun möchten, ist den nächsten dist-Ordner zu konfigurieren (ich wollte dist in root).

Beachten Sie, dass wir dem Ordner ../ voranstellen.

// src/next.config.js
module.exports = {
  distDir: '../dist'
}

// package.json
  "scripts": {
    "dev": "next ./src",
    "build": "next build ./src",
    "start": "next start ./src",
    ..
  },

@msegers Ich versuche, diesem Setup zu folgen und

Cannot find module 'next/document'
Cannot find module 'next/error'
...

auf HTTP-Anfrage (keine Fehler in der Importphase). Irgendeine Idee, wie man das beheben kann?

Die Forderung, pages im Root zu haben, macht mich wirklich wahnsinnig – für alles, was wirklich groß ist, stapeln sich die Dinge unkontrolliert im Root: Stile, Komponenten, Client-Speicher, Konfigurationsdateien usw. Ich wünschte, es gäbe einen Workaround.

Ergänzung: versucht, pages mit client/pages zu verknüpfen. Die meisten Sachen scheinen zu funktionieren, außer Hot Reload. Traurig :(

@msegers Vorschlag hat bei mir funktioniert.

Wenn Sie next-i18next verwenden, stellen Sie sicher, dass Sie den richtigen localePath in der NextI18-Konfiguration eingestellt haben: localePath: 'src/static/locales/',

So was :

NextI18NextInstance = new NextI18Next({
  defaultLanguage: 'en',
  otherLanguages: ['en'],
  debug: true,
  localePath: 'src/static/locales/',
});

Es scheint einen großen Appetit darauf zu geben - ich würde gerne konfigurieren können, wo meine Top-Level-Seiten gesucht werden.

@malimccalla Das kannst du hier: https://github.com/slaterbbx/fullstackinator

Vorbehalt

Sie können den Namen des Ordners meines Wissens nicht ändern, muss "Seiten" bleiben

Wie

Sehen Sie im Client-Ordner nach. Beachten Sie, dass dafür einige wichtige Dinge erforderlich sind. Das Beispiel, das ich zeige, ist für ein benutzerdefiniertes Serverszenario + Typoskript, aber es ist im Grunde dasselbe, die Kerndinge sind.

1. Stellen Sie in den Skripten in package.json sicher, dass Sie auf den Ordner ( next ./client ) statt nur ( next ) für "npm run dev" zeigen / tun Sie dasselbe für build script
2. In diesem Ordner ( ./client ) benötigen Sie eine Datei next.config.js. Dann einfach folgendes drin haben:

module.exports = {
    distDir: '../.next' // so that you can tell it to go up a folder for the dev and prod files.
}

Wenn Sie Fragen haben, können Sie mir gerne eine E-Mail senden oder hier ist auch in Ordnung.

UPDATE: Mir ist gerade aufgefallen, dass @brainkim oben belassen , da das verlinkte Beispiel einen viel komplexeren Anwendungsfall für jeden zeigt, der ein solches Beispiel sucht.

Danke dafür @slaterbbx

Mein Problem ist, dass ich versuche, konzeptionell verwandten Code gemeinsam zu platzieren. Ich habe folgende Struktur

├── components
|   ├──  GridItem.tsx
|   ├──  Avatar.tsx
|   └──  Button.tsx
├── pages
|   └── profile
|       └── components
|       |   ├── CoverPhoto.tsx
|       |   └── UserInterests.tsx
|       ├── data.ts
|       ├── styles.ts
|       └── index.tsx

Das Problem bei diesem Ansatz (wie von @timneutkens aufgezeigt) besteht darin, dass alle Dateien in pages als Webpack-Einstiegspunkte behandelt werden, die wiederum für die Commonchunks-Konfiguration berücksichtigt werden. Wie es derzeit aussieht, unterstützt Next nur Seitenkomponenten der obersten Ebene innerhalb von pages . Wenn ich konfigurieren könnte, wo nach Seiten gesucht wird, könnte ich diese (vernünftige?) Struktur beibehalten. ich stelle mir sowas in der config vor

pages: ["./pages/*/index.tsx"]

Es könnte auch für Projekte verwendet werden, die Seiten an mehreren Orten speichern

pages: ["./pages/*", "./admin-pages/*"]

oder Projekte, die ihre Komponenten der obersten Ebene in einem Ordner mit einem anderen Namen speichern möchten

pages: ["./views/*"]

oder Projekte, die nur den Pfad anpassen möchten

pages: ["./src/custom/path/to/pages/*"]

Ich glaube, dies ist ein faires Feature und es fühlt sich nicht wie ein radikales Muster an ( Garn-Arbeitsbereiche verwenden das gleiche Muster, um workspaces , ein Muster, das Next.js selbst implementiert ).

@malimccalla ah, ja, verstehe deine Trauer voll und ganz, ich wünsche mir auch eine voll flexible Lösung. Möglicherweise auch etwas, das es wert ist, einen Beitrag zu leisten, aber ich habe gelesen, dass sie nicht daran interessiert sind, eine Lösung anzubieten (irgendwo, aber zitieren Sie mich nicht), daher befürchte ich, dass die Investition einer solchen Zeit in eine solche Funktion verloren gehen könnte. Es sei denn, sie bestätigen natürlich, dass sie an einem solchen Beitrag interessiert sind, aber es könnte ein Projekt sein, das man in Betracht ziehen sollte 🙋‍♂️

@malimccalla konnten Sie als nächstes gut mit Ihrer gewünschten Projektstruktur spielen oder haben Sie Ihr pages Verzeichnis abgeflacht und die Seitenunterkomponenten woanders gespeichert?

@joncursi Ich habe es geschafft, das Verzeichnis pages in views umzubenennen und dann ein neues pages Verzeichnis zu erstellen, dessen einziger Zweck darin besteht, die Seitenkomponenten der obersten Ebene zu exportieren.

zum Beispiel sieht pages/profile.tsx jetzt so aus:

export { default } from "../views/profile"  

es ist keineswegs ideal, erlaubt mir aber, meine gewünschte Projektstruktur beizubehalten

@folofse Das Ändern des i18n localePath funktioniert beim Scannen des Verzeichnisses. Aber beim Auflösen von Sprachdateien wird src wieder entfernt. Was ist zu tun?

Ich habe Debug aktiviert, um die Protokolle wie folgt bereitzustellen (i18next)

...
  localePath: 'src/static/locales',
  localeStructure: '{{lng}}/{{ns}}',
  localeSubpaths: 'foreign',
  backend:
   { loadPath:
      'V:/dev/some-project/static/locales/{{lng}}/{{ns}}.json',
     addPath:
      'V:/dev/some-project/static/locales/{{lng}}/{{ns}}.missing.json' },
  allLanguages: [ 'de', 'de' ],

loadPath ist auf *\static\locales , sollte aber *\src\static\locales .

Frage:

Wir haben eine benutzerdefinierte Serverdatei in /projectRoot/next-web/server.js

Es mountet /projectRoop/next-renderer-universal/client wie folgt:

// in /projectRoot/next-web/server.js
const nextApp = next({
  dev: NODE_ENV !== 'production',
  dir: APP_DIR,
  quiet: false,
});

Wie zum Teufel bauen und versenden wir das eigentlich :)?

@armenr Diese kleine App von mir könnte helfen. Es verwendet einen benutzerdefinierten Einstiegspunkt ( src/server.ts ) und ruft next() wie folgt
https://gitlab.com/kachkaev/website-frontend/blob/e1c7106cf63811f6341c4bd47dd2354eb2546914/src/server.ts#L11 -18

Alle Quelldateien unter PROJECT_ROOT/src (oder einem anderen Unterverzeichnis) zu halten, ist in Next.js eine ziemliche Herausforderung. Durch die hinzugefügte automatische TS-Integration in Next 9 wird es sogar noch etwas chaotischer 😔 Ich wünschte, https://github.com/zeit/next.js/issues/4315 wäre wieder geöffnet.

:) Ich habe ein Monorepo eingerichtet, also wurde die Frage, die ich stellte, durch andere Komplexitäten erschwert

Seitdem haben wir genau herausgefunden, was zu tun ist, aber ich schätze den Beispielcode. Trotzdem nützlich! Danke schön :)

@armenr Was ist Ihre Problemumgehung in Bezug auf Monorepo? Ich habe mein Projekt mit lerna aufgesetzt und bin immer noch damit eingeschränkt.

@anoop-gupt

Lerna-, Monorepo-, Garn-Arbeitsbereiche und separate packages.

Ich lege den gesamten Front-End-Code in einen Ordner, den ich renderer-universal nenne. Ich habe dann ein Paket namens next-web in dem ich meinen benutzerdefinierten nächsten Server behalte. Ich habe auch ein anderes Paket, in dem ich nextron behalte (nächstes + Elektron ... ausgezeichnetes Projekt, schau sie auf GitHub nach).

In der Datei server.js für nextron und next-web verwende ich:

const nextApp = next({
  dev: NODE_ENV !== 'production',
  dir: APP_DIR,
  quiet: false,
});

Und ich übergebe die Verzeichnisposition des Renderer-Universal-Pakets über ENV-Variablen an diese Serverdateien.

Ich habe auch eine Reihe von Microservices, die wir geschrieben haben, die sich auch in anderen Lerna-Paketen im Monorepo befinden.

Keine benutzerdefinierten Webpack-/Babel-Konfigurationen oder Symlink-Auflösung erforderlich.

Normalerweise bevorzuge ich diese Projektstruktur:

  - api
  - pages
  - utils

Der Ordner src obersten Ebene ist normal und wird von vielen Projekten verwendet. Warum nicht ?

@revskill10 Ja , sogar ich habe diese Struktur bevorzugt.

Wir verteilen unsere App & Services + NextJS sowohl in Desktop/Cloud-Hybriden als auch in Web-Builds.

Paketverwaltung - Duplizierung von node_modules, die Notwendigkeit benutzerdefinierter serverJS-Dateien mit Next und gemeinsam genutzte Module und Libs zwischen den verschiedenen Microservices machten es schwierig, alles auseinander zu brechen oder der herkömmlichen/einfacheren Verzeichnisstruktur zu folgen.

Um meinem Team ein leicht zu verwaltendes Setup zu bieten, musste ich ein Muster entwickeln, das es uns ermöglicht, gleichzeitig an Desktop- und Webversionen zu arbeiten, und alle Microservices zu entkoppeln und alle gemeinsam genutzten Bibliotheken und Module zwischen ihnen zu deduplizieren. Der einzige wirklich "richtige" Weg, dies zu tun, war über das Setup, das ich beschrieben habe.

Für den durchschnittlichen Projektstart ist dies übertrieben. In unserem Fall hatten wir eine ziemlich klare Vorstellung von unseren anfänglichen Anforderungen und dem, was wir bauen mussten, also habe ich nur die Frage beantwortet.

Für was es wert ist, denken wir daran, die benutzerdefinierte Datei server.js loszuwerden und stattdessen zum /api-Layout zu wechseln, das in Next9 implementiert wurde. Ob wir damit noch problemlos on/build web + nextron simultan auf einfache Art und Weise entwickeln können, ist noch unklar.

@armenr Kann ich bitte Ihren Repository-Speicherort haben? Es scheint eine gute Lösung zu sein.

Die Methode distDir: '../dist', funktioniert in Next 9 mit Typoskript und Kundenserver nicht mehr. Das Problem ist, dass ein tsconfig.json im src Verzeichnis erstellt wird.

Ich habe ein paar Stunden damit verbracht, das Problem zu lösen, musste aber alles in das Root-Verzeichnis verschieben ... so ein Durcheinander

Ich habe ein paar Stunden damit verbracht, das Problem zu lösen, musste aber alles in das Root-Verzeichnis verschieben ... so ein Durcheinander

Es ändert sich nichts, wenn Sie versuchen, mit Pfadauflösungen herumzuspielen oder die Einstiegspunktdatei in Ihrer tsconfig.json zu ändern?

Dies wird seit 2017 angefordert. Wie können wir helfen, diese Funktion bereitzustellen?

@timneutkens Bitte überlege es dir noch einmal

@janhesters https://github.com/zeit/next.js/issues/8415

Habe hier geantwortet, werde dieses Problem lösen.
https://github.com/zeit/next.js/issues/4315#issuecomment -522263598