Next.js: ¿Cómo cambiar el lugar en el que Next busca las páginas?

AFAIK, no puedes. Puede deshabilitar el enrutamiento del sistema de archivos a través de next.config.js .

Según los documentos, dir especifica la ubicación del proyecto, por lo que la forma correcta sería establecerlo en ./src :

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

Pero solo se usa en una API programática (con un servidor personalizado) y también afectará la ubicación presunta de otros archivos (como el directorio next.config.js y static , creo).

No tengo idea de lo que dicen estos otros comentarios, pero puede configurar qué directorio next.js busca páginas desde la línea de comandos:

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

No puede cambiar el directorio, y no estamos planeando cambiar esto, busque un problema en el rastreador de problemas (incluidos los problemas cerrados) en el futuro antes de publicar un problema, ya que esta pregunta ha surgido varias veces. .

@timneutkens no es como el mantenedor de moment.js, quien rechazó la optimización para aplicaciones del lado del cliente, lo que lleva a configuraciones personalizadas en muchos proyectos, incluso en CRA.
Muchos proyectos repetidos tienen una carpeta src , donde se encuentran los archivos.

Como este es actualmente el primer resultado en Google al buscar esto, ¿quizás sería beneficioso explicar el razonamiento detrás de esa decisión @timneutkens ?

Como lo indica @brainkim, jus agregue los scripts json de su paquete con ./src. Lo que también puede querer hacer es configurar la siguiente carpeta dist (quería dist en la raíz).

Tenga en cuenta que anteponemos la carpeta con ../.

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

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

@msegers Estoy tratando de seguir esta configuración y

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

en solicitud HTTP (sin errores en la fase de importación). ¿Alguna idea de como arreglarlo?

El requisito de tener pages en la raíz realmente me vuelve loco: para cualquier cosa realmente grande, las cosas comienzan a acumularse en la raíz de manera incontrolable: estilos, componentes, tienda de clientes, archivos de configuración, etc. Ojalá hubiera una solución.

Adición: intentó enlazar simbólicamente pages a client/pages . La mayoría de las cosas parecen funcionar, excepto Hot Reload. Triste :(

@msegers La sugerencia funcionó para mí.

Si usa next-i18next, asegúrese de establecer el localePath correcto en la configuración de NextI18: localePath: 'src/static/locales/',

Como esto :

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

Parece haber bastante apetito por esto: me encantaría poder configurar dónde se buscan mis páginas de nivel superior.

@malimccalla Puede, consulte aquí: https://github.com/slaterbbx/fullstackinator

Advertencia

Hasta donde yo sé, no se puede cambiar el nombre de la carpeta, debe permanecer "páginas"

Cómo

Mire en la carpeta del cliente, observe que hay algunas cosas clave necesarias para que esto suceda. El ejemplo que muestro es para un escenario de servidor personalizado + mecanografiado, pero es básicamente lo mismo, las cosas principales son.

1. En los scripts en package.json, asegúrese de apuntar a la carpeta (siguiente ./cliente) en lugar de solo (siguiente) para "npm run dev" / haga lo mismo con el script de compilación
2. En esa carpeta (./client) necesitará un archivo next.config.js. Entonces simplemente tenga en él lo siguiente:

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

Si tiene alguna pregunta, no dude en enviarme un correo electrónico o aquí también está bien.

ACTUALIZACIÓN: Acabo de notar que arriba @brainkim da exactamente la misma explicación. Lo siento, pero dejaré esto porque el ejemplo vinculado muestra un caso de uso mucho más complejo para cualquiera que busque un ejemplo de este tipo.

Gracias por esto @slaterbbx

Mi problema es que estoy tratando de coubicar código relacionado conceptualmente. Tengo la siguiente estructura

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

El problema con este enfoque (como lo señaló @timneutkens) es que todos los archivos dentro de pages se tratan como puntos de entrada del paquete web, por lo que a su vez se consideran para la configuración de commonchunks. Tal como está actualmente, Next solo admite componentes de página de nivel superior dentro de pages . Si pudiera configurar dónde se buscan las páginas, podría mantener esta estructura (¿razonable?). Me imagino algo como esto en la configuración.

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

También podría usarse para proyectos que almacenan páginas en múltiples ubicaciones.

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

o proyectos que quieran almacenar sus componentes de nivel superior en una carpeta con un nombre diferente

pages: ["./views/*"]

o proyectos que solo quieren personalizar la ruta

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

Creo que esta es una característica justa y no se siente como un patrón radical (los espacios de trabajo de hilo usan el mismo patrón para ubicar workspaces , un patrón que Next.js implementa ).

@malimccalla ah, sí, entiendo totalmente tu dolor, también deseo una solución totalmente flexible. Posiblemente en algo que valga la pena contribuir con un esfuerzo también, pero he leído que no están interesados ​​en ofrecer una solución (en algún lugar, pero no me cites al respecto), así que me temo que invertir tanto tiempo en tal característica podría ser una causa perdida. A menos que, por supuesto, confirmen que estarían interesados ​​en tal contribución, nuevamente, podría ser un proyecto para considerar emprender 🙋‍♂️

@malimccalla , ¿ pages y almacenando los subcomponentes de la página en otro lugar?

@joncursi Me las arreglé para pages a views y luego creando un nuevo directorio pages cuyo único propósito es exportar los componentes de la página de nivel superior.

por ejemplo pages/profile.tsx ahora se ve así:

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

de ninguna manera es ideal, pero me permite mantener la estructura de proyecto deseada

@folofse El cambio de i18n localePath funciona cuando se trata de escanear el directorio. Pero al resolver archivos de idioma, está eliminando src nuevamente. ¿Qué hacer?

Activé la depuración para proporcionar los registros de la siguiente manera (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 se establece en *\static\locales pero debería ser *\src\static\locales .

Pregunta:

Tenemos un archivo de servidor personalizado en /projectRoot/next-web/server.js

Se monta /projectRoop/next-renderer-universal/client así:

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

¿Cómo diablos construimos y enviamos esto :)?

@armenr Esta pequeña aplicación mía podría ayudar. Utiliza un punto de entrada personalizado ( src/server.ts ) y así es como llama next() :
https://gitlab.com/kachkaev/website-frontend/blob/e1c7106cf63811f6341c4bd47dd2354eb2546914/src/server.ts#L11 -18

Mantener todos los archivos de origen en PROJECT_ROOT/src (u otro subdirectorio) es bastante desafiante en Next.js. Debido a la integración automática de TS agregada en Next 9, las cosas incluso se vuelven un poco más complicadas 😔 Ojalá se volviera a abrir https://github.com/zeit/next.js/issues/4315 .

:) Configuré un monorepo, por lo que la pregunta que estaba haciendo se vio agravada por otras complejidades

Desde entonces, hemos descubierto exactamente qué hacer, pero agradezco el código de muestra. ¡Sigue siendo útil! Gracias :)

@armenr ¿Cuál es su solución con respecto a monorepo? Configuré mi proyecto con lerna y todavía estoy limitado.

@ anoop-gupt

Lerna, monorepo, espacios de trabajo de hilo y packages. separados

Pongo todo el código de front-end en una carpeta que llamo renderer-universal . Luego tengo un paquete llamado next-web donde guardo mi próximo servidor personalizado. También tengo otro paquete donde guardo nextron (siguiente + electrón ... excelente proyecto, búscalos en GitHub).

En el archivo server.js para nextron y next-web, uso:

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

Y paso la ubicación del directorio del paquete renderer-universal a través de variables ENV a esos archivos del servidor.

También tengo un montón de microservicios que escribimos que residen en otros paquetes de lerna en monorepo.

No se requieren configuraciones personalizadas de webpack / babel ni resolución de enlace simbólico.

Normalmente, prefiero esta estructura de proyecto:

  - api
  - pages
  - utils

La carpeta de nivel superior src es normal y muchos proyectos la utilizan. Por qué no ?

@ revskill10 Sí , incluso yo preferí esa estructura.

Estamos distribuyendo nuestra aplicación y servicios + NextJS tanto en híbridos de escritorio / nube como en compilaciones web.

Gestión de paquetes: la duplicación de node_modules, la necesidad de archivos serverJS personalizados con Next, y los módulos y bibliotecas compartidos entre los diferentes microservicios hicieron que fuera difícil separar todo o seguir la estructura de directorios convencional / más simple.

Para proporcionar una configuración fácilmente manejable para mi equipo, tuve que idear un patrón que nos permitiera trabajar en versiones de escritorio y web simultáneamente, y para desacoplar todos los microservicios y deduplicar todas las bibliotecas y módulos compartidos entre ellos. La única forma "correcta" de hacerlo era a través de la configuración que he descrito.

Para el proyecto promedio que comienza, esto es una exageración. En nuestro caso, teníamos una comprensión razonablemente clara de nuestros requisitos iniciales y lo que necesitábamos construir, así que solo estaba respondiendo a la pregunta.

Por lo que vale, estamos pensando en deshacernos del archivo server.js personalizado y, en su lugar, pasar al diseño / api que se implementó en Next9. No está claro, hasta el momento, si esto todavía nos permitirá desarrollar / construir web + nextron simultáneamente de una manera simple.

@armenr ¿Puedo

El método distDir: '../dist', ya no funciona en Next 9 con mecanografiado y servidor de cliente. El problema es que crea un tsconfig.json en el directorio src .

Pasé un par de horas tratando de resolver esto, pero tuve que mover todo al directorio raíz ... un desastre 😞

Pasé un par de horas tratando de resolver esto, pero tuve que mover todo al directorio raíz ... un desastre 😞

¿No cambia nada si intenta jugar con las resoluciones de ruta o modificar el archivo de punto de entrada en su tsconfig.json?

Esto se ha solicitado desde 2017. ¿Cómo podemos ayudar a que se envíe esta función?

@timneutkens , vuelva a abrir este problema y reconsidere

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

Respondido aquí, vamos a bloquear este problema.
https://github.com/zeit/next.js/issues/4315#issuecomment -522263598