Next.js: Comment changer où Next recherche les pages ?

AFAIK, vous ne pouvez pas. Vous pouvez désactiver le routage du système de fichiers via next.config.js .

Selon la documentation, dir spécifie l'emplacement du projet, donc la bonne façon serait de le définir sur ./src :

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

Mais il n'est utilisé que dans une API de programmation (avec un serveur personnalisé) et affectera également l'emplacement présumé d'autres fichiers (comme le répertoire next.config.js et static , je crois).

Aucune idée de ce que disent ces autres commentaires, mais vous pouvez configurer dans quel répertoire next.js recherche les pages à partir de la ligne de commande :

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

Vous ne pouvez pas changer le répertoire, et nous ne prévoyons pas de changer cela, veuillez rechercher un problème sur le suivi des problèmes (y compris les problèmes fermés) à l'avenir avant de publier un problème, car cette question a été soulevée plusieurs fois .

@timneutkens ne
Beaucoup de modèles de projet ont un dossier src , où se trouvent les fichiers.

Comme il s'agit actuellement du premier résultat sur google lors de la recherche de ceci, il serait peut-être utile d'expliquer le raisonnement derrière cette décision @timneutkens ?

Comme indiqué par @brainkim, ajoutez simplement les scripts json de votre package avec ./src. Ce que vous voudrez peut-être aussi faire, c'est configurer le dossier dist suivant (je voulais dist à la racine).

Notez que nous préparons le dossier avec ../.

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

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

@msegers J'essaie de suivre cette configuration et j'obtiens des tonnes d'erreurs comme celle-ci :

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

sur requête HTTP (pas d'erreurs en phase d'import). Une idée de comment y remédier ?

L'exigence d'avoir pages à la racine me rend vraiment dingue - pour tout ce qui est réaliste, les choses commencent à s'accumuler à la racine de manière incontrôlable : styles, composants, magasin client, fichiers de configuration, etc. J'aimerais qu'il y ait une solution de contournement.

Ajout : j'ai essayé de créer pages lien symbolique entre client/pages . La plupart des choses semblent fonctionner, sauf Hot Reload. Triste :(

La suggestion de

Si vous utilisez next-i18next, assurez-vous de définir le bon localePath dans la configuration NextI18 : localePath: 'src/static/locales/',

Comme ça :

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

Il semble y avoir tout un appétit pour cela - j'adorerais pouvoir configurer où mes pages de niveau supérieur sont recherchées.

@malimccalla Vous pouvez, consultez ici : https://github.com/slaterbbx/fullstackinator

Caveat

Vous ne pouvez pas changer le nom du dossier pour autant que je sache, doit rester "pages"

Comment

Regardez dans le dossier client, notez qu'il y a quelques éléments clés nécessaires pour que cela se produise. L'exemple que je montre concerne un scénario de serveur personnalisé + un script dactylographié, mais c'est fondamentalement la même chose, les choses essentielles sont.

1. Dans les scripts de package.json, assurez-vous de pointer vers le dossier ( next ./client ) au lieu de juste ( next ) pour " npm run dev " / faites de même pour le script de construction
2. Dans ce dossier ( ./client ), vous aurez besoin d'un fichier next.config.js. Ensuite, il suffit d'y avoir ce qui suit :

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

Si vous avez des questions, n'hésitez pas à m'envoyer un e-mail ou c'est bien aussi.

MISE À JOUR : je viens de remarquer que ci-dessus @brainkim donne exactement la même explication. Désolé, je vais laisser cela car l'exemple lié montre un cas d'utilisation beaucoup plus complexe pour quiconque cherche un tel exemple.

Merci pour ce @slaterbbx

Mon problème est que j'essaie de co-localiser le code conceptuellement lié. j'ai la structure suivante

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

Le problème avec cette approche (comme l'a souligné @timneutkens) est que tous les fichiers dans pages sont traités comme des points d'entrée webpack donc à leur tour pris en compte pour la configuration commonchunks. Dans l'état actuel des choses, Next ne prend en charge que les composants de page de niveau supérieur dans pages . Si je pouvais configurer où les pages sont recherchées, je pourrais conserver cette structure (raisonnable ?). J'imagine quelque chose comme ça dans la config

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

Il peut également être utilisé pour des projets qui stockent des pages dans plusieurs emplacements

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

ou des projets qui souhaitent stocker leurs composants de niveau supérieur dans un dossier nommé différemment

pages: ["./views/*"]

ou des projets qui veulent juste personnaliser le chemin

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

Je pense que c'est une fonctionnalité juste à avoir et cela ne ressemble pas à un modèle radical (les espaces de travail de fil utilisent le même modèle pour localiser workspaces , un modèle que Next.js lui-même implémente ).

@malimccalla ah, oui, comprenez parfaitement votre chagrin, je souhaite également une solution entièrement flexible. Peut-être quelque chose qui vaut la peine de contribuer aussi, mais j'ai lu qu'ils ne sont pas intéressés à offrir une solution (quelque part, mais ne me citez pas là-dessus), donc je crains qu'investir autant de temps dans une telle fonctionnalité ne soit une cause perdue. A moins bien sûr qu'ils ne confirment qu'ils seraient intéressés par une telle contribution, là encore, cela pourrait être un projet à envisager de réaliser 🙋‍♂️

@malimccalla avez-vous pu jouer avec la structure de votre projet souhaitée, ou avez-vous fini par aplatir votre répertoire pages et stocker les sous-composants de la page ailleurs ?

@joncursi J'ai réussi à contourner le pages en views , puis en créant un nouveau répertoire pages seul but est d'exporter les composants de page de niveau supérieur.

par exemple pages/profile.tsx ressemble maintenant à ceci :

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

ce n'est en aucun cas l'idéal mais me permet de garder la structure de projet souhaitée

@folofse changer le localePath i18n fonctionne lorsqu'il s'agit d'analyser le répertoire. Mais lors de la résolution des fichiers de langue, il supprime à nouveau src. Que faire?

J'ai activé le débogage pour fournir les journaux comme suit (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 est défini sur *\static\locales mais il devrait être *\src\static\locales .

Question:

Nous avons un fichier de serveur personnalisé en /projectRoot/next-web/server.js

Il monte /projectRoop/next-renderer-universal/client comme ceci :

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

Comment diable pouvons-nous réellement construire et expédier cela :) ?

@armenr Cette petite application pourrait m'aider. Il utilise un point d'entrée personnalisé ( src/server.ts ) et voici comment il appelle next() :
https://gitlab.com/kachkaev/website-frontend/blob/e1c7106cf63811f6341c4bd47dd2354eb2546914/src/server.ts#L11 -18

Garder tous les fichiers source sous PROJECT_ROOT/src (ou un autre sous-répertoire) est assez difficile dans Next.js. En raison de l'intégration automatique de TS dans Next 9, les choses deviennent même un peu plus compliquées 😔 J'aimerais que https://github.com/zeit/next.js/issues/4315 soit rouvert.

:) J'ai mis en place un monorepo, donc la question que je posais était aggravée par d'autres complexités

Depuis, nous avons compris exactement quoi faire, mais j'apprécie l'exemple de code. Toujours utile ! Merci :)

@armenr Quelle est votre solution de contournement en ce qui concerne le monorepo ? J'ai monté mon projet avec lerna et j'y suis toujours contraint.

@anoop-gupt

Lerna, monorepo, espaces de travail en laine et packages. séparés

J'ai mis tout le code frontal dans un dossier que j'appelle renderer-universal . J'ai alors un package appelé next-web où je garde mon prochain serveur personnalisé. J'ai aussi un autre package où je garde nextron (suivant + électron... excellent projet, recherchez-les sur GitHub).

Dans le fichier server.js pour nextron et next-web, j'utilise :

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

Et je transmets l'emplacement du répertoire du package renderer-universal via les variables ENV à ces fichiers de serveur.

J'ai également un tas de microservices que nous avons écrits résidant dans d'autres packages lerna dans le monorepo également.

Aucune configuration webpack/babel personnalisée ou résolution de lien symbolique requise.

Normalement, je préfère cette structure de projet :

  - api
  - pages
  - utils

Le dossier src niveau supérieur est normal et de nombreux projets l'utilisent. Pourquoi pas ?

@revskill10 Oui , même moi, j'ai préféré cette structure.

Nous distribuons notre application et nos services + NextJS dans les hybrides de bureau/cloud ainsi que dans les versions Web.

La gestion des packages - la duplication de node_modules, le besoin de fichiers serverJS personnalisés avec Next, et les modules et bibliothèques partagés entre les différents microservices ont rendu difficile la séparation de tout ou le suivi de la structure de répertoire conventionnelle/simple.

Pour fournir une configuration facilement gérable à mon équipe, j'ai dû trouver un modèle qui nous permette de travailler simultanément sur les versions de bureau et Web, et de découpler tous les microservices et de dédupliquer toutes les bibliothèques et modules partagés entre eux. La seule vraie "bonne" façon de le faire était via la configuration que j'ai décrite.

Pour le projet moyen qui démarre, c'est exagéré. Dans notre cas, nous avions une compréhension assez claire de nos exigences initiales et de ce que nous devions construire, alors je répondais simplement à la question.

Pour ce que cela vaut, nous envisageons de nous débarrasser du fichier server.js personnalisé et de passer à la disposition / api qui a été implémentée dans Next9. On ne sait pas encore si cela nous permettra de développer facilement/construire web + nextron simultanément et de manière simple.

@armenr Puis-je avoir l'emplacement de votre référentiel, s'il vous plaît ? Cela semble une bonne solution.

La méthode distDir: '../dist', ne fonctionne plus dans Next 9 avec dactylographié et serveur client. Le problème est qu'il crée un tsconfig.json dans le src .

J'ai passé quelques heures à essayer de résoudre ce problème, mais j'ai dû tout déplacer dans le répertoire racine ... un tel gâchis 😞

J'ai passé quelques heures à essayer de résoudre ce problème, mais j'ai dû tout déplacer dans le répertoire racine ... un tel gâchis 😞

Rien ne change si vous essayez de jouer avec les résolutions de chemin ou de modifier le fichier de point d'entrée dans votre tsconfig.json ?

Cela est demandé depuis 2017. Comment pouvons-nous aider à faire livrer cette fonctionnalité ?

@timneutkens s'il vous plaît rouvrir ce problème et reconsidérer

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

Répondu ici, va verrouiller ce problème.
https://github.com/zeit/next.js/issues/4315#issuecomment -522263598