Как Go определяет состав пакета из исходных файлов одной директории?
Go формирует пакет из исходных файлов одной директории, которые подходят под текущую платформу и build constraints и имеют одно и то же объявление package. Файлы с другим именем пакета обычно приводят к ошибке компиляции; исключение — специальные внешние тесты с суффиксом _test.
Пакет в Go задуман как простая единица компиляции и повторного использования: разработчику не нужно вручную перечислять файлы, входящие в модуль. Достаточно организовать исходники по директориям, а компилятор и инструменты Go сами определяют состав пакета с учётом условий сборки.
Такой подход уменьшает количество конфигурации, но делает структуру каталогов частью архитектуры проекта: файлы в одной директории по умолчанию претендуют на принадлежность к одному пакету.
Ошибка в объявлении package, неверный build constraint или смешение обычных и тестовых файлов может привести к тому, что файл не попадёт в сборку либо пакет перестанет компилироваться. Особенно опасно ожидать, что два файла в одной директории автоматически образуют разные независимые пакеты.
Нужно также отличать директорию пакета от его имени и import path. Импортируется пакет по пути, а обращение к его экспортированным именам обычно выполняется через имя, указанное в объявлении package.
При сборке Go рассматривает файлы исходного пакета в одной директории и отбрасывает те, которые не подходят по build constraints, имени файла для конкретной ОС или архитектуры либо другим правилам выбора файлов. Оставшиеся обычные исходные файлы должны объявлять одно и то же имя пакета.
Файлы с суффиксом _test.go используются тестовым инструментарием отдельно. Они могут принадлежать тому же пакету или внешнему тестовому пакету с именем, образованным добавлением _test; это позволяет проверять публичное поведение пакета без доступа к его внутренним именам.
Имя пакета не обязано совпадать с последним компонентом import path, хотя обычно совпадает для читаемости. Внутри одного пакета файлы совместно видят его объявления с учётом областей видимости, поэтому разбиение кода по файлам не создаёт дополнительной границы доступа.
Из этого следуют практические ограничения: разные логические компоненты нужно размещать в разных директориях, а платформенный код — отделять build constraints или именами файлов. Нельзя использовать имя файла как механизм сокрытия объявления от других файлов того же пакета; для этого применяются неэкспортируемые имена и отдельные пакеты.
Команда разместила реализацию HTTP-клиента и вспомогательный генератор в одной директории. Один файл объявили как пакет client, другой — как пакет generator, рассчитывая получить два компонента без дополнительных каталогов. Сборка завершилась ошибкой из-за несовместимых объявлений пакета.
Рассматривались два варианта: переименовать объявление пакета в обоих файлах или разнести файлы по каталогам. Первый вариант устранял ошибку, но оставлял несвязанные компоненты в одной единице компиляции и усложнял зависимости. Выбрали разные директории: это явно выразило границу пакетов, упростило импорты и позволило независимо тестировать компоненты.
Вопрос: Видят ли файлы одного пакета объявления друг друга независимо от того, в каком файле они находятся?
Ответ: Да, разбиение пакета по файлам не создаёт области видимости на уровне файла. Объявления пакета доступны согласно обычным правилам видимости Go: неэкспортируемые имена доступны всему тому же пакету, а экспортируемые — также из импортирующих пакетов. Порядок расположения объявлений в файлах обычно не ограничивает их использование.
Вопрос: Может ли один каталог одновременно содержать обычный пакет и внешний тестовый пакет?
Ответ: Да, но только в тестовых файлах с суффиксом _test.go. Основные файлы образуют, например, пакет client, а внешний тестовый файл может объявлять client_test и обращаться только к доступному извне API. Обычный файл без _test.go не может объявить такое другое имя пакета рядом с основным пакетом.
Вопрос: Почему файл с build constraint не всегда считается частью пакета?
Ответ: Перед компиляцией Go проверяет, выполняются ли условия, заданные для файла. Если файл предназначен для другой операционной системы, архитектуры или набора пользовательских тегов, он исключается из текущего варианта сборки. Поэтому отсутствие объявления или функции в текущей сборке может быть намеренным, но если для выбранных условий не осталось совместимого набора файлов, пакет может завершить сборку ошибкой.