Next.js: Como alterar onde o Next procura as páginas?

AFAIK, você não pode. Você pode desativar o roteamento do sistema de arquivos por meio de next.config.js .

De acordo com os documentos, dir especifica a localização do projeto, então a maneira correta seria defini-lo como ./src :

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

Mas ele só é usado em uma API programática (com um servidor personalizado) e afetará a localização presumida de outros arquivos também (como o diretório next.config.js e static , acredito).

Não tenho ideia do que esses outros comentários estão dizendo, mas você pode configurar qual diretório next.js procura por páginas na linha de comando:

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

Você não pode alterar o diretório e não estamos planejando alterá-lo. Pesquise um problema no rastreador de problemas (incluindo problemas encerrados) no futuro antes de postar um problema, pois essa questão surgiu várias vezes .

@timneutkens não é como o mantenedor do moment.js, que rejeitou a otimização para aplicativos do lado do cliente, o que levou a configurações personalizadas em muitos projetos, até mesmo em CRA.
Muitos boilerplates de projeto têm uma pasta src , onde estão os arquivos.

Como este é atualmente o primeiro resultado no Google ao pesquisar isso, talvez seja útil explicar o motivo por trás dessa decisão @timneutkens ?

Conforme declarado por @brainkim ,

Observe que adicionamos ../ ao início da pasta.

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

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

@msegers Estou tentando seguir esta configuração e obtendo

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

na solicitação HTTP (sem erros na fase de importação). Alguma ideia de como consertar isso?

O requisito de ter pages na raiz realmente me deixa louco - para qualquer coisa realisticamente grande, as coisas começam a se acumular na raiz de forma incontrolável: estilos, componentes, armazenamento do cliente, arquivos de configuração, etc. Gostaria que houvesse uma solução alternativa.

Adição: tentei criar um link simbólico pages para client/pages . A maioria das coisas parece funcionar, exceto Hot Reload. Triste :(

A sugestão de

Se você usar next-i18next, certifique-se de definir o localePath correto na configuração NextI18: localePath: 'src/static/locales/',

Como isso :

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

Parece haver um grande apetite para isso - adoraria ser capaz de configurar onde minhas páginas de nível superior são procuradas.

@malimccalla Você pode, verifique aqui: https://github.com/slaterbbx/fullstackinator

Embargo

Você não pode mudar o nome da pasta, tanto quanto eu sei, precisa ficar "páginas"

Quão

Olhe na pasta do cliente e observe que há algumas coisas importantes necessárias para que isso aconteça. O exemplo que mostro é para um cenário de servidor personalizado + texto digitado, mas é basicamente a mesma coisa, as coisas principais são.

1. Nos scripts em package.json, certifique-se de apontar para a pasta (próximo ./client) em vez de apenas (próximo) para "npm run dev" / faça o mesmo para o script de construção
2. Nessa pasta (./client), você precisará de um arquivo next.config.js. Em seguida, basta incluir o seguinte:

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

Se você tiver alguma dúvida, fique à vontade para me enviar um e-mail ou aqui está bom também.

ATUALIZAÇÃO: acabei de notar que o @brainkim acima dá exatamente a mesma explicação. Desculpe, vou deixar isso porque o exemplo vinculado mostra um caso de uso muito mais complexo para quem está procurando por um exemplo.

Obrigado por este @slaterbbx

Meu problema é que estou tentando co-localizar código conceitualmente relacionado. Eu tenho a seguinte estrutura

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

O problema com essa abordagem (conforme apontado por @timneutkens) é que todos os arquivos dentro de pages são tratados como pontos de entrada do webpack, portanto, considerados para a configuração de commonchunks. Como está atualmente, Next só oferece suporte a componentes de página de nível superior em pages . Se eu pudesse configurar onde as páginas são procuradas, poderia manter essa estrutura (razoável?). Eu imagino algo assim na configuração

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

Também pode ser usado para projetos que armazenam páginas em vários locais

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

ou projetos que desejam armazenar seus componentes de nível superior em uma pasta com um nome diferente

pages: ["./views/*"]

ou projetos que querem apenas personalizar o caminho

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

Acredito que esse seja um recurso justo de se ter e não parece um padrão radical (os espaços de trabalho do yarn usam o mesmo padrão para localizar workspaces , um padrão que o próprio Next.js implementa ).

@malimccalla ah, sim, entendo totalmente sua dor, também desejo uma solução totalmente flexível. Possivelmente algo que valha a pena contribuir com um esforço também, mas eu li que eles não estão interessados ​​em oferecer uma solução (em algum lugar, mas não me cite nisso), então temo que investir tanto tempo em tal recurso possa ser uma causa perdida. A menos, é claro, que eles confirmem que estariam interessados ​​em tal contribuição, então, novamente, pode ser um projeto a considerar a realização 🙋‍♂️

@malimccalla , você conseguiu jogar bem com a estrutura de projeto desejada ou acabou pages e armazenando os subcomponentes da página em outro lugar?

@joncursi Consegui contornar o problema renomeando o diretório pages para views e, em seguida, criando um novo diretório pages cujo único propósito é exportar os componentes da página de nível superior.

por exemplo pages/profile.tsx agora se parece com isto:

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

de forma alguma é ideal, mas me permite manter minha estrutura de projeto desejada

@folofse alterar o i18n localePath funciona quando se trata de escanear o diretório. Mas ao resolver arquivos de idioma, ele está removendo src novamente. O que fazer?

Eu habilitei a depuração para fornecer os logs da seguinte forma (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á definido como *\static\locales mas deve ser *\src\static\locales .

Pergunta:

Temos um arquivo de servidor personalizado em /projectRoot/next-web/server.js

Ele monta /projectRoop/next-renderer-universal/client assim:

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

Como diabos nós realmente construímos e enviamos isso :)?

@armenr Este pequeno aplicativo meu pode ajudar. Ele usa um ponto de entrada personalizado ( src/server.ts ) e é assim que chama next() :
https://gitlab.com/kachkaev/website-frontend/blob/e1c7106cf63811f6341c4bd47dd2354eb2546914/src/server.ts#L11 -18

Manter todos os arquivos de origem sob PROJECT_ROOT/src (ou outro subdiretório) é bastante desafiador em Next.js. Por causa da integração automática de TS no Next 9, as coisas ficaram um pouco mais complicadas 😔 Gostaria que https://github.com/zeit/next.js/issues/4315 fosse reaberto.

:) Eu configurei um monorepo, então a pergunta que eu estava fazendo era composta por outras complexidades

Desde então, descobrimos exatamente o que fazer, mas agradeço o código de amostra. Ainda é útil! Obrigada :)

@armenr Qual é a sua solução alternativa em relação ao monorepo? Eu montei meu projeto com a lerna e ainda estou restrito a ele.

@ anoop-gupt

Lerna, monorepo, espaços de trabalho de yarn e separados packages.

Coloquei todo o código do front-end em uma pasta que chamo de renderer-universal . Eu tenho um pacote chamado next-web onde mantenho meu próximo servidor personalizado. Eu também tenho outro pacote onde guardo nextron (next + electron ... excelente projeto, procure-os no GitHub).

No arquivo server.js para nextron e next-web, eu uso:

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

E eu passo a localização do diretório do pacote universal renderizador por meio de variáveis ​​ENV para esses arquivos do servidor.

Eu também tenho um monte de microsserviços que escrevemos residindo em outros pacotes lerna no monorepo também.

Nenhuma configuração de webpack / babel customizada ou resolução de link simbólico necessária.

Normalmente, eu prefiro esta estrutura de projeto:

  - api
  - pages
  - utils

A pasta de nível superior src é normal e muitos projetos a utilizam. Por que não ?

@ revskill10 Sim , até eu preferia essa estrutura.

Estamos distribuindo nosso aplicativo e serviços + NextJS tanto em híbridos de desktop / nuvem quanto em compilações web.

Gerenciamento de pacotes - duplicação de node_modules, a necessidade de arquivos serverJS personalizados com Next e módulos e libs compartilhados entre os diferentes microsserviços tornavam difícil separar tudo ou seguir a estrutura de diretório convencional / mais simples.

Para fornecer uma configuração facilmente gerenciável para minha equipe, tive que criar um padrão que nos permitisse trabalhar em versões desktop e web simultaneamente, e para desacoplar todos os microsserviços e desduplicar todas as bibliotecas e módulos compartilhados entre eles. A única maneira "certa" real de fazer isso era por meio da configuração que descrevi.

Para o projeto médio que está começando, isso é um exagero. Em nosso caso, tínhamos um entendimento razoavelmente claro de nossos requisitos iniciais e o que precisávamos construir, então eu estava apenas respondendo à pergunta.

Pelo que vale a pena, estamos pensando em nos livrar do arquivo server.js personalizado e, em vez disso, mudar para o layout / api que foi implementado no Next9. Não está claro, até o momento, se isso ainda tornará facilmente possível para nós desenvolvermos / construirmos web + nextron simultaneamente de uma maneira simples.

@armenr Posso

O método distDir: '../dist', não funciona mais no Next 9 com texto datilografado e servidor de cliente. O problema é que ele cria um tsconfig.json no diretório src .

Gastei algumas horas tentando resolver isso, mas tive que mover tudo para o diretório raiz ... que bagunça 😞

Gastei algumas horas tentando resolver isso, mas tive que mover tudo para o diretório raiz ... que bagunça 😞

Nada muda se você tentar mexer com resoluções de caminho ou modificar o arquivo de ponto de entrada em seu tsconfig.json?

Isso é solicitado desde 2017. Como podemos ajudar no envio desse recurso?

@timneutkens reabra este problema e reconsidere

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

Respondido aqui, vou bloquear este problema.
https://github.com/zeit/next.js/issues/4315#issuecomment -522263598