Поиск…
Вступление
Перед выпуском Meteor 1.3 разработчики Meteor были разочарованы обработкой Meteor.js файловых зависимостей и глобальных переменных. В ответ Метеор установил новые стандарты для проектных структур, чтобы сделать систему зависимостей проекта более упорядоченной. В этом разделе объясняется стандартизованная структура проекта и принципы, лежащие в его основе.
замечания
клиент
Весь код в каталоге клиента запускается только на стороне клиента или в веб-браузере.
клиент / совместимость
Каталог совместимости содержит устаревший или сторонний код, например библиотеки jQuery и т. Д.
Lib
Каталог lib загружается перед другими каталогами в вашем проекте Meteor и загружается как на сервере, так и на клиента. Это предпочтительное место для определения моделей данных, изоморфных библиотек и бизнес-логики.
импорт
Каталог импорта - это каталог на сервере, доступный как для сервера, так и для клиента, но только до того, как клиентский пакет будет отправлен клиенту.
пакеты
Каталог пакетов - это где пользовательские пакеты хранятся во время локальной разработки. При использовании стандартной команды meteor add package:name для добавления пакета Meteor будет выглядеть первым в этом каталоге, если локальный пакет имеет соответствующее имя описания в файле package.js . Если нет, он будет опросить Атмосферу как обычно.
частный
Частный каталог содержит статические файлы, которые должны быть доступны только на веб-сервере.
общественности
Общий каталог содержит статические файлы, доступные только на клиенте приложения. Это может включать в себя активы брендинга и т. Д.
сервер
Каталог сервера содержит серверные активы. Это может включать логику аутентификации, методы и другой код, которые могут потребовать рассмотрения безопасности.
тесты
Каталоги тестов опущены по умолчанию, когда ваше приложение в комплекте и развернуто.
Как было предложено Ричардом Сильвертоном , удобной идеей является размещение не только каталога проекта метеоров под контролем версий, но и его родительского каталога.
Таким образом, вы можете хранить файлы под контролем версий, не имея метеор для борьбы с ним.
Классические структуры каталогов
Первое, что вам нужно знать при структурировании ваших приложений, - это то, что инструмент Meteor имеет некоторые каталоги, жестко закодированные с определенной логикой. На самом базовом уровне следующие каталоги «запекаются» в пакете «Метеор».
client/ # client application code
client/compatibility/ # legacy 3rd party javascript libraries
imports/ # for lazy loading feature
lib/ # any common code for client/server.
packages/ # place for all your atmosphere packages
private/ # static files that only the server knows about
public/ # static files that are available to the client
server/ # server code
tests/ # unit test files (won't be loaded on client or server)
Справочная страница: Руководство Meteor> Специальные каталоги
Структура каталога только для пакета
Многие люди оказываются в конечном итоге поддержкой нескольких приложений и хотят поделиться кодом между приложениями. Это приводит к концепции архитектуры микросервиса и приложений для всех пакетов. По сути, код из всей классической структуры каталогов реорганизуется в пакеты.
Несмотря на отсутствие жестко закодированной логики для каталогов в пакетах, мы обнаруживаем, что при создании пакетов рекомендуется использовать классическую структуру каталогов. Это создает естественный путь рефакторинга, поскольку функции прототипируются в приложении, а затем извлекаются в пакеты, которые должны публиковаться и совместно использоваться. Имена каталогов разделяются, поэтому среди членов команды меньше путаницы.
client/ # client application code
packages/ # place for all your atmosphere packages
packages/foo/client # client application code
packages/foo/lib # any common code for client/server
packages/foo/server # server code
packages/foo/tests # tests
server/ # server code
Структура каталогов импорта / модулей
Самые последние версии корабля Метеор с поддержкой ecmascript , иначе ES6 или ES2015. Вместо пакетов Javascript теперь поддерживает import и модули, что заменяет необходимость в приложениях только для пакетов. Последняя структура каталогов похожа на структуру только для пакетов, но использует каталог /imports вместо /packages .
imports #
imports/api # isomorphic methods
imports/lib # any common code for client/server
imports/client # client application code
imports/server # server code
Структура каталога смешанного режима
И, конечно же, вы можете смешивать эти подходы и использовать как пакеты, так и импорт вдоль вашего кода, специфичного для вашего приложения. Структура смешанного режима наиболее распространена в трех ситуациях: приложение franken, которое просто немного отвлекает отсюда - и - там без какой-либо общей стратегии; приложение, которое активно реорганизуется из структур Classic или Package-Only в структуру Imports / Modules.
client/ # client application code
client/compatibility/ # legacy 3rd party javascript libraries
imports #
imports/api # isomorphic methods
imports/lib # any common code for client/server
imports/client # client application code
imports/server # server code
lib/ # any common code for client/server.
packages/ # place for all your atmosphere packages
packages/foo/client # client application code
packages/foo/lib # any common code for client/server
packages/foo/server # server code
packages/foo/tests # tests
private/ # static files that only the server knows about
public/ # static files that are available to the client
server/ # server code
tests/ # unit test files (won't be loaded on client or server)
Порядок загрузки каталога
Файлы шаблонов HTML всегда загружаются перед всем остальным
Файлы, начинающиеся с основного. загружаются последними
Затем загружаются файлы внутри любого каталога lib /
Затем загружаются файлы с более глубокими путями
Затем файлы загружаются в алфавитном порядке по всему пути
Справочная страница: Руководство Meteor> Структура приложения> Порядок загрузки файлов по умолчанию