Comments 12

А вторая версия уже вышла? В первой немало проблем было для не совсем стандартных случаев, вроде тех, когда нужно поддерживать несколько index.html страниц.

Как всегда, автор натягивает сову на глобус ради того, чтобы просто статью написать. По сути, единственная разумная причина — это первая, которая решается средствами, которые автор сам же и упоминает — customize-cra или craco (react-app-rewired вроде считается устаревшим со второй версии CRA).


Вторая причина — откровенно ниочём. Ну да, начинающий так будет думать. Но если начинающего ткнуть в настройку вебпака — он с криками убежит и больше никогда не вернётся. Так что надо будет — пойдёт и изучит, из чего CRA состоит и как его правильно настраивать. Рано или поздно это всегда придётся сделать, но я бы сказал, что лучше это делать после того, как ты поигрался со своим первым сайтом и решил углубиться.


А насчёт перегруженности возможностями вообще претензию не понял. Ладно бы эта перегруженность какое-то влияние на производительность/размер бандла/сложность настройки влияние оказывало, так нет же. На это окажут влияние, скорее, кривые руки при самостоятельной настройке вебпака.


А ещё можно нехило поджечь кресло, дебажа bin/start.js автора, куда он напихал просто неведомую хрень. Особенно уровень неведомого будет зашкаливать для начинающего, о котором автор, вроде бы, заботится. И эту хрень поддерживать он, в отличие от авторов CRA, конечно же, не будет, так что любые изменения и хотелки придётся вносить самостоятельно. За это автора, кстати, неплохо пропесочили в комментах исходной статьи.


Треш, короче. Конечно, разбираться в том, из чего CRA состоит — полезно и даже необходимо. Но отказываться от инструмента при этом — совершенно необязательно.

Давно ищё ответ на вопрос, почему мне нужно бояться команды eject? Что в этом плохого?
Я воспринимаю cra — как отличный отдебаженный инструмент, который разрабатывают много хороших разработчиков. И это как стартовая настройка для проектов (типа prettier-а, чтоб не было разногласий в команде.). И если вдруг нужно что-то добавить/кастомизировать — делаем eject. Так вот в чём проблема eject-а? почему я не должен его делать?

Всё дело в обновлениях. Поддерживать приложение, основанное на CRA без eject очень легко — по сути, за весь билд отвечает команда CRA, а всё, что нужно девелоперу — просто обновиться.


Если же ты сделал eject, то проще держать все зависимости залоченными, потому что постоянно обновлять их (а зависимости, используемые CRA, выходят часто) — очень тяжело. Зато легко что-нибудь сломать в билде.


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


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

У меня лично был опыт проекта, который стартовали именно извлечением из CRA + TypeScript. Кастомизаций было совсем немного, но уже к моему приходу в компанию часть зависимостей устарела (примерно на год).


Суммарно ушло около 8 месяцев, чтобы обновить всё до актуальной версии и "запихнуть обратно" (параллельно с поддержкой и разработкой высоко-нагруженного проекта).


В обновлённую версию мы уже добавили кастомизацию, которая корректировала некоторые хотелки, но больше никакого eject.


Сами разработчики рекомендуют делать форк темплейта (если уж очень надо) и вносить необходимые изменения до установки, чтобы было легче потом обновлять. На сайте CRA есть ссылка на статью.


P.S. Для себя – это очень полезная и интересная практика посмотреть, что там под капотом.

как отличный отдебаженный инструмент, который разрабатывают много хороших разработчиков

Правда хороших? Я когда eject делал, плевался на чём свет стоит. Огромные файлы состоящие преимущественно из лапши. Никакой внятной декомпозиции. Просто хаос творится. Единственное что их спасает — тонны комментариев с прикреплёнными ссылками на issues. Постороннему человеку такое поддерживать будет очень непросто.


Когда я переписал всё это с декомпозицией, внезапно, окалось, что всё можно сделать и просто, и аккуратно, и сохравнив всё необходимое (и разумеется добавив свои хотелки). Да, для этого нужно много времени, да требуется опытный разработчик, да придётся продираться через клубок сложной конфигурации. Но сделать это по уму более чем реально.


В чём проблема eject-а? Вот сделала команда eject, т.к. не хватило ей чего-то. А потом пытались поддерживать эту лапшу со своими примесями. С каждым изменением это становилось всё более и более тяжелой задачей. Любые изменения касающиеся SSR сервера и webpack-конфига превращались в агонию. При всём при этом за год таких мучений CRA ушёл вперёд и стал работать во многом иначе. Так что просто подсмотреть как у них — было часто бесперспективным вариантом. Менялись либы, конфиг опции, в целом подходы.


По итогу полный отказ от CRA и создание своего велосипеда. Взяли только то, что сами используем. Сконфигурировали так что можно миддла это править посадить. Разбили всё на десятка два мелких функций, с внятными названиями, где отдельно взятая задача решается цельно, а не разбросана по всему 700+ строчному файлу. Все костыли тоже аккуратно прокомментировали. Ну и добавили свои хотелки, разумеется. Из того что я бы изменил повтори я это снова — я бы написал конфигурацию на TS, добавив руками типы там, где их нет.


Для меня вывод простой — если у вас большой и сложный проект, много своих хотелок, и достаточно бюджета времени на то чтобы сшить конфиг под свои нужды, тогда не заигрывайтесь с CRA. А сделав eject, просто выпиливайте его целиком. Сразу. Сэкономите себе кучу времени и нервов. Ну и денег :)


Ну и к изначальной цитате. Почему-то многие люди думают, что если проект имеет много звёздочек, то там внутри не говнокод. Бывает это и так. Но в случае, скажем, с npm, cra, enzyme, telegram — это совсем не так. Мне просто больно было копаться в их кодовой базе.

спасибо, что поделились.

Для меня вывод простой — если у вас большой и сложный проект, много своих хотелок, и достаточно бюджета времени на то чтобы сшить конфиг под свои нужды, тогда не заигрывайтесь с CRA. А сделав eject, просто выпиливайте его целиком.

Хотелок не сильно много. Там декораты для mobx-а добавить, там svgo какой-нибудь прикрутить. Впринципе, полностью понимаем, что после eject-а мы сами по себе, и постепенно «заменяем» cra-шный конфиг своим по мере развития проекта.
Но фишка в том, что в самом начале мы-то секономили кучу времени за счёт того, что другие (команда facebook или кто там разрабатывает cra) его потратили.
Мы ведь не знаем на старте как дальше проект пойдёт, может и cra достаточно будет, а если не будет — пожалуйста eject. Я именно поэтому недоумевал — что плохого, чтоб сначала взять cra-конфиг секономив время, а потом допиливать его по мере развития проекта (после eject-а под свою ответственность понятное дело).
Главное что узнал со стати делать исполняемый файл. Только не понял почему он сделал alias для react вроде с этим кодом ничего не изменится или я не прав?
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
ruvds.com
Employees
11–30 employees
Registered

Habr blog