Next.js: Как изменить место, где Next будет искать страницы?

AFAIK, вы не можете. Вы можете отключить маршрутизацию файловой системы с помощью next.config.js .

Согласно документации, dir указывает местоположение проекта, поэтому правильным способом было бы установить его на ./src :

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

Но он используется только в программном API (с настраиваемым сервером) и также повлияет на предполагаемое расположение других файлов (например, next.config.js и static каталог, я полагаю).

Понятия не имею, что говорят эти другие комментарии, но вы можете настроить, какой каталог next.js будет искать страницы из командной строки:

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

Вы не можете изменить каталог, и мы не планируем это менять, пожалуйста, поищите проблему в системе отслеживания проблем (включая закрытые проблемы) в будущем, прежде чем публиковать проблему, так как этот вопрос возникал довольно много раз .

@timneutkens не похожи на разработчика moment.js, который отверг оптимизацию для клиентских приложений, что привело к настраиваемым конфигурациям во многих проектах, даже в CRA.
У многих шаблонов проектов есть папка src , в которой лежат файлы.

Поскольку в настоящее время это первый результат поиска в Google, возможно, было бы полезно объяснить причину этого решения

Как указано в @brainkim jus, добавьте json-скрипты вашего пакета с помощью ./src. Что вы также можете сделать, так это настроить следующую папку dist (я хотел, чтобы dist находился в корне).

Обратите внимание, что мы добавляем к папке ../.

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

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

@msegers Я пытаюсь следовать этой настройке и получаю

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

по HTTP-запросу (на этапе импорта ошибок нет). Есть идеи, как это исправить?

Требование иметь pages в корневом каталоге действительно сводит меня с ума - для чего-то реально большого в корне начинает бесконтрольно накапливаться вещи: стили, компоненты, клиентское хранилище, файлы конфигурации и т. Д. Жаль, что не было обходного пути.

Дополнение: попытался создать символическую ссылку pages на client/pages . Кажется, что все работает, кроме Hot Reload. Грустный :(

Предложение @msegers у меня сработало.

Если вы используете next-i18next, убедитесь, что вы установили правильный localePath в конфигурации NextI18: localePath: 'src/static/locales/',

Нравится :

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

Похоже, это вызывает большой аппетит - хотелось бы иметь возможность настраивать, где будут искать мои страницы верхнего уровня.

@malimccalla Вы можете проверить здесь: https://github.com/slaterbbx/fullstackinator

Предостережение

Вы не можете изменить название папки, насколько я знаю, должны оставаться "страницы"

Как

Загляните в папку клиента и обратите внимание, что для этого нужно несколько важных вещей. Пример, который я показываю, предназначен для пользовательского сценария сервера + машинописный текст, но это в основном то же самое, основные вещи.

1. В сценариях в package.json убедитесь, что указали папку (next ./client) вместо просто (next) для "npm run dev" / сделайте то же самое для сценария сборки
2. В этой папке (./client) вам понадобится файл next.config.js. Тогда просто имейте в нем следующее:

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

Если у вас есть какие-либо вопросы, не стесняйтесь отправить мне электронное письмо или здесь тоже.

ОБНОВЛЕНИЕ: я только что заметил, что @brainkim выше дает точно такое же объяснение ... Извините, я оставлю это, потому что связанный пример показывает гораздо более сложный вариант использования для всех, кто ищет такой пример.

Спасибо за это @slaterbbx

Моя проблема в том, что я пытаюсь совместить концептуально связанный код. У меня следующая структура

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

Проблема с этим подходом (как указано @timneutkens) заключается в том, что все файлы в pages обрабатываются как точки входа в веб-пакет, поэтому, в свою очередь, рассматриваются для конфигурации commonchunks. В настоящее время Next поддерживает только компоненты страницы верхнего уровня в пределах pages . Если бы я мог настроить, где искать страницы, я бы сохранил эту (разумную?) Структуру. Представляю что-то подобное в конфиге

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

Его также можно использовать для проектов, которые хранят страницы в нескольких местах.

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

или проекты, которые хотят хранить свои компоненты верхнего уровня в папке с другим именем

pages: ["./views/*"]

или проекты, которые просто хотят настроить путь

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

Я считаю , что это особенность справедливо , чтобы и он не чувствует , как радикальный шаблон ( пряжа рабочих области используют один и тот же шаблон , чтобы найти workspaces , шаблон самого Next.js инвентаря ).

@malimccalla ах, да, полностью понимаю ваше горе, я также хочу полностью гибкое решение. Возможно, что-то тоже стоит того, чтобы приложить усилия, но я читал, что они не заинтересованы в предложении решения (где-то, но не цитируйте меня по этому поводу), поэтому я опасаюсь, что вложение такого времени в такую ​​функцию может быть безнадежным. Если, конечно, они не подтвердят, что будут заинтересованы в таком вкладе, опять же, это может быть проект, о котором стоит подумать 🙋‍♂️

@malimccalla. Удалось ли вам перейти дальше, чтобы хорошо поиграть с желаемой структурой проекта, или вы в конечном итоге выровняли свой каталог pages и сохранили подкомпоненты страницы в другом месте?

@joncursi Мне удалось pages в views а затем создав новый каталог pages единственной целью которого является экспорт компонентов страницы верхнего уровня.

например pages/profile.tsx теперь выглядит так:

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

это ни в коем случае не идеально, но позволяет мне сохранить желаемую структуру проекта

@folofse изменение i18n localePath работает, когда дело доходит до сканирования каталога. Но при разрешении языковых файлов он снова удаляет src. Что делать?

Я включил отладку, чтобы предоставить журналы следующим образом (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 имеет значение *\static\locales но должно быть *\src\static\locales .

Вопрос:

У нас есть собственный файл сервера в /projectRoot/next-web/server.js

Он монтирует /projectRoop/next-renderer-universal/client вот так:

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

Как, черт возьми, мы на самом деле построим и отправим это :)?

@armenr Это небольшое мое приложение может помочь. Он использует настраиваемую точку входа ( src/server.ts ), и вот как он вызывает next() :
https://gitlab.com/kachkaev/website-frontend/blob/e1c7106cf63811f6341c4bd47dd2354eb2546914/src/server.ts#L11 -18

Хранить все исходные файлы в PROJECT_ROOT/src (или другом подкаталоге) в Next.js. довольно сложно. Из-за добавленной автоматической интеграции TS в Next 9 все стало даже немного запутаннее 😔 Я бы хотел, чтобы https://github.com/zeit/next.js/issues/4315 был повторно открыт.

:) Я настроил монорепозиторий, поэтому вопрос, который я задавал, усугублялся другими сложностями.

С тех пор мы точно выяснили, что делать, но я ценю образец кода. Все еще полезно! Спасибо :)

@armenr Какое решение вы можете использовать в отношении монорепозитория? Я создал свой проект с помощью lerna, но все еще ограничивался им.

@ anoop-gupt

Lerna, monorepo, пряжа рабочие пространства и отдельные packages.

Я помещаю весь интерфейсный код в папку, которую называю renderer-universal . Затем у меня есть пакет под названием next-web котором я сохраняю свой следующий сервер. У меня также есть еще один пакет, в котором я храню nextron (следующий + электрон ... отличный проект, поищите их на GitHub).

В файле server.js для nextron и next-web я использую:

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

И я передаю расположение каталога универсального пакета визуализации через переменные ENV в эти файлы сервера.

У меня также есть несколько микросервисов, которые мы написали, находящиеся в других пакетах lerna в монорепозитории.

Не требуется настраиваемых конфигураций webpack / babel или разрешения символических ссылок.

Обычно я предпочитаю такую ​​структуру проекта:

  - api
  - pages
  - utils

Папка верхнего уровня src - это нормально, и ее используют многие проекты. Почему нет ?

@ revskill10 Да , даже я предпочел эту структуру.

Мы распространяем наше приложение и сервисы + NextJS как на гибриды настольных компьютеров и облаков, так и на веб-сборки.

Управление пакетами - дублирование node_modules, необходимость в настраиваемых файлах serverJS с Next, а также общих модулях и библиотеках между различными микросервисами затрудняло разбиение всего на части или следование традиционной / более простой структуре каталогов.

Чтобы обеспечить легко управляемую настройку для моей команды, мне пришлось придумать шаблон, который позволил бы нам работать над настольной и веб-версиями одновременно, а также разделить все микросервисы и дедуплицировать все общие библиотеки и модули между ними. Единственный реальный «правильный» способ сделать это - использовать описанную мною установку.

Для среднего начинающего проекта это перебор. В нашем случае у нас было достаточно четкое представление о наших начальных требованиях и о том, что нам нужно построить, поэтому я просто отвечал на вопрос.

Как бы то ни было, мы думаем о том, чтобы избавиться от настраиваемого файла server.js и вместо этого перейти к макету / api, который был реализован в Next9. Пока неясно, позволит ли нам по-прежнему легко разрабатывать / создавать web + nextron одновременно простым способом.

@armenr Могу я

Метод distDir: '../dist', больше не работает в Next 9 с машинописным текстом и клиентским сервером. Проблема в том, что он создает tsconfig.json в каталоге src .

Потратил пару часов, пытаясь решить эту проблему, но пришлось переместить все в корневой каталог ... такой беспорядок 😞

Потратил пару часов, пытаясь решить эту проблему, но пришлось переместить все в корневой каталог ... такой беспорядок 😞

Ничего не изменится, если вы попробуете возиться с разрешениями путей или изменить файл точки входа в tsconfig.json?

Это запрашивается с 2017 года. Как мы можем помочь с поставкой этой функции?

@timneutkens, пожалуйста,

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

Ответил здесь, собираюсь заблокировать эту проблему.
https://github.com/zeit/next.js/issues/4315#issuecomment -522263598