Website development
JavaScript
Node.JS
GitHub
Comments 21
0

Если положить файл CNAME в папку public, то react-scripts скопируют его в build при сборке.


Так можно избавиться от костыля с echo.

0

Думал об этом. Но тогда будет костыль с лежащим в public/ (я думал, что лучше в build/ и под гит занести) файлом CNAME, а так все, что относится к деплою хотя бы хранится в одном конфиге, я считаю это меньшим из зол. Остальному коду должно быть плевать на деплой

0

Папка public предназначена для любых файлов, которые должны оказаться в корне сайта. В документации react-scripts есть список примеров, что туда можно положить.


Файл CNAME вполне подходит по критерию "You need a file with a specific name in the build output".

0

не соглашусь.
Мне не нужен файл CNAME на моем сайте. Мне он нужен в репозитории github, чтобы github pages адекватно работал с доменом.


Приложение может быть задеплоено и в другом месте. Так что в public/ на мой взгляд этому файлу точно делать нечего

0

Нашел интересную ссылку: https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/template/README.md#step-5-optionally-configure-the-domain


Официальная документация советует делать именно так — через public folder.


В своем проекте вы можете делать как вам удобно, но если работать в команде — то ваше ноу-хау принесет боли программистам, которые не будут понимать откуда берется файл, если его нет.

0

Я ответил Вам, почему считаю такой подход неразумным.


Мой код не должен знать что-то о тонкостях хостинга и зависеть от него. CNAME — это черта исключительно github.io, соответственно, она должна находиться только в коде, осуществляющим деплой.


Anyway, я считаю оба варианта костыльными, так что кому что

0

Для меня документация к утилите, генерирующей проект (не фреймворк), не является авторитетом.


Директория public используется многими фреймворками и должна использоваться для хранения статических файлов, которые должны быть доступны "as is" для отдачи сервером. В пример можно привести рельсы и express (хотя там название все же опционально). Вы же предлагаете там хранить файлы конфигурации хостинга. Подход с добавлением файла в public проще, но все так же является костылем. И то, что об этом написано в документации (причем документации к утилите), этого не отменяет


Не понимаю, зачем Вы продолжаете этот тред.

0

Спасибо за наводку!


Быстро сейчас глянул. Как я понял, он нужен для деплоя с локальной машины. У меня же деплой происходит через CI.


Т.е. от меня требуется просто запушить изменения в мастер, CI запустит тесты, билд и если все ок, то задеплоит уже на github.io

0

У меня через этот пакет идёт деплой с Gitlab CI. Ну и от этого у меня появляется возможность использовать Gitlab Pages как промежуточный вариант

0

как видите, в тревисе этот функционал есть из коробки=)

0
+1 зависимость от стороннего сервиса. Плюс GitLab-а — его можно развернуть на своем сервере. А можно отдельно у себя разместить приватный раннер для GitLab CI, и потому не зависеть от внешних CI-сервисов
0
Сам по себе GitLab является таким же сторонним сервисом. А «своего сервера» у человека, который использует github pages, может и не быть вовсе.
0
Да, но ничто не запрещает запустить на своем сервере свой GitLab (напомню, GitLab распространяется бесплатно, и каждый может его у себя поднять)
0
Похоже, мы не так друг друга поняли.

Моя точка зрения: Travis CI — +1 сервис, от работы которого зависит проект
Добавим к нему GitHub — уже 2 сервиса. Один не работает — и все встало.

В альтернативу я предлагаю GitLab, который предлагает либо не зависеть от сторонних сервисов вообще (сам устанавливаешь к себе), либо, если и зависеть, то только от одного сервиса
+1

с таким же успехом можно деплоить и с локальной машины, с помощью скриптов. В чем смысл вашего подхода? В том, что тревис неожиданно упасть может? Это смех


Смысл поста в том, чтобы продемонстрировать, что веб-приложения с гитхаба могут "изкаробки" деплоиться на pages с помощью бесплатного и известного travis ci

+1

Я сначала в заголовке прочитал "долой" вместо "деплой" и заинтересовался

+1
Если не используется custom domain, то сайт будет находиться по адресу yourname.github.io/projectname, и тем самым у меня ломались абсолютные пути (например, /favicon.ico). Я не стал думать над решением, т.к. у меня используется отдельный домен.

Если в package.json добавить «homepage»:"./", то все пути до статики в «сбилженом» index.html будут относительно текущей папки.
0

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


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


Спасибо!

Only those users with full accounts are able to leave comments., please.