Как стать автором
Обновить

Комментарии 6

"действия этого скрипта НЕОТВРАТИМЫ" — точно сказано, почти все проекты, которые видел использующими CRA, сделали eject и перешли на кастомные конфиги по мере роста проекта. Он только для маленьких pet-проджектов, так как для проектов чуть больше нужно много дополнительного функционала, а возня с переопределением правил изначально плохая идея.


По телу статьи — вы забыли упомянуть, что в IDE может потребоваться специальным образом отметить папки, для которых сделаны алиасы — так, WebStorm умеет брать ts-алиасы в ts-файлах, но в стилевых файлах @import 'mixins.scss' не сработает без отметки Resource Root на папке src/components/styles. У вас вижу css-in-js, поэтому могли не столкнуться. Также в кодовых блоках лучше использовать двойной пробел для табуляции и переносить при достижении 80-100 символов — читать легче, не будет прокрутки.


За лесенку в const ... = require() уважение, выглядит аккуратно. Жаль, не разбито по семантическим группам (built-ins, external, internal etc.), в этом случае скорость восприятия кода еще улучшится.


По коду еще по неймингу захотелось пройтись. Вот, к примеру, функция


const slicePath = p => p.slice(0, p.indexOf('*') - 1)

Как видно из названия, она "нарезает путь". Из реализации не очень понятно, что ожидается на вход и что будет на выходе. Даже если найти пример входных данных в коде ("src/components/*"), все равно не сразу понятно, что будет на выходе — обрежется только звездочка или еще что-то. Только поразбиравшись станет понятно, что на выходе получится "src/components". Почему бы не сделать более читабельно:


const removeWildcardPart = path => path.replace('/*', '');

Примерно то же и с .reduce((obj, x) => { ... }). Так как тут не используется TypeScript, то главным оружием в борьбе за понятность структур в коде является семантичность. И вариант с .reduce((acc, path) => { ... }) будет выглядеть лучше, а еще лучше — вынести это в отдельную функцию, чтобы следующий разработчик не тратил время на разбор, если его это не интересует. К тому же эти вездесущие нейминги x — в последнем кодовом блоке возник дубляж названий:


(obj, x) => {... options.paths[x].map(x => `${slicePath(x)}`) ...}

а это уже тянет на вопрос юниору на собеседованиях — какие недостатки у подобного подхода) А так норм, добро пожаловать в писательское сообщество.

Спасибо, нейминг функции и переменных исправил) А с проблемами восприятия EDA и правда пока не сталкивался.
Чтобы избежать импортов с первой картинки, как вариант можно прописать в tsconfig/jsconfig
"baseUrl": "src",

Тогда импорты будут выглядеть примерно вот так
import RouteLeaveGuard from 'components/service/RouteLeaveGuard';
import ConfirmDialog from 'components/ui/ConfirmDialog';
import { preventSubmit, scrollErrorIntoView } from 'helpers/forms/tools';
Да, некоторые проблемы это решит, но не решит то, для чего вообще был написал этот туториал.
Path Aliases мы создаем для того, чтоб иметь удобные импорты к абсолютно любой директории проекта, для которой мы посчитаем это необходимым. А таким методом только для директорий верхних уровней.
Решил такую задачу в проекте с CRA, TypeScript и CRACO следующим образом:

1. В craco конфиге добавляем произвольные пути, как и показано в статье (webpack.aliase);
2. В tsconfig добавляем эти же пути в paths и указываем baseUrl;

Но!, CRA официально не поддерживает aliased imports, и даже выпиливает это из tsconfig при старте/сборке, и решением стало разделить tsconfig на два файла:

3. Конфиг положить в файл, скажем, tsconfig.base.json, а в tsconfig.json сделать только extends. Тогда CRA сообщит, что «compilerOptions.paths must not be set (aliased imports are not supported)», но не сможет их выпилить, и всё прекрасно работает

Нашёл на просторах, решение меня полностью устраивает, eject не понадобился.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории