Комментарии 21
Если положить файл CNAME в папку public, то react-scripts скопируют его в build при сборке.
Так можно избавиться от костыля с echo.
Думал об этом. Но тогда будет костыль с лежащим в public/
(я думал, что лучше в build/
и под гит занести) файлом CNAME, а так все, что относится к деплою хотя бы хранится в одном конфиге, я считаю это меньшим из зол. Остальному коду должно быть плевать на деплой
Папка public предназначена для любых файлов, которые должны оказаться в корне сайта. В документации react-scripts есть список примеров, что туда можно положить.
Файл CNAME вполне подходит по критерию "You need a file with a specific name in the build output".
не соглашусь.
Мне не нужен файл CNAME на моем сайте. Мне он нужен в репозитории github, чтобы github pages адекватно работал с доменом.
Приложение может быть задеплоено и в другом месте. Так что в public/
на мой взгляд этому файлу точно делать нечего
Нашел интересную ссылку: https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/template/README.md#step-5-optionally-configure-the-domain
Официальная документация советует делать именно так — через public folder.
В своем проекте вы можете делать как вам удобно, но если работать в команде — то ваше ноу-хау принесет боли программистам, которые не будут понимать откуда берется файл, если его нет.
Я ответил Вам, почему считаю такой подход неразумным.
Мой код не должен знать что-то о тонкостях хостинга и зависеть от него. CNAME — это черта исключительно github.io, соответственно, она должна находиться только в коде, осуществляющим деплой.
Anyway, я считаю оба варианта костыльными, так что кому что
github.com/m8rge/webpage/blob/gh-pages/CNAME
aputilov.ru/CNAME — 404
Делайте как в документации, не придумывайте ненужных велосипедов =)
Для меня документация к утилите, генерирующей проект (не фреймворк), не является авторитетом.
Директория public используется многими фреймворками и должна использоваться для хранения статических файлов, которые должны быть доступны "as is" для отдачи сервером. В пример можно привести рельсы и express (хотя там название все же опционально). Вы же предлагаете там хранить файлы конфигурации хостинга. Подход с добавлением файла в public проще, но все так же является костылем. И то, что об этом написано в документации (причем документации к утилите), этого не отменяет
Не понимаю, зачем Вы продолжаете этот тред.
Всю описаную работу он делает сам
Спасибо за наводку!
Быстро сейчас глянул. Как я понял, он нужен для деплоя с локальной машины. У меня же деплой происходит через CI.
Т.е. от меня требуется просто запушить изменения в мастер, CI запустит тесты, билд и если все ок, то задеплоит уже на github.io
У меня через этот пакет идёт деплой с Gitlab CI. Ну и от этого у меня появляется возможность использовать Gitlab Pages как промежуточный вариант
как видите, в тревисе этот функционал есть из коробки=)
Моя точка зрения: Travis CI — +1 сервис, от работы которого зависит проект
Добавим к нему GitHub — уже 2 сервиса. Один не работает — и все встало.
В альтернативу я предлагаю GitLab, который предлагает либо не зависеть от сторонних сервисов вообще (сам устанавливаешь к себе), либо, если и зависеть, то только от одного сервиса
с таким же успехом можно деплоить и с локальной машины, с помощью скриптов. В чем смысл вашего подхода? В том, что тревис неожиданно упасть может? Это смех
Смысл поста в том, чтобы продемонстрировать, что веб-приложения с гитхаба могут "изкаробки" деплоиться на pages с помощью бесплатного и известного travis ci
Я сначала в заголовке прочитал "долой" вместо "деплой" и заинтересовался
Если не используется custom domain, то сайт будет находиться по адресу yourname.github.io/projectname, и тем самым у меня ломались абсолютные пути (например, /favicon.ico). Я не стал думать над решением, т.к. у меня используется отдельный домен.
Если в package.json добавить «homepage»:"./", то все пути до статики в «сбилженом» index.html будут относительно текущей папки.
Деплой webpack-приложения на github.io с помощью Travis CI