Комментарии 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)}`) ...}
а это уже тянет на вопрос юниору на собеседованиях — какие недостатки у подобного подхода) А так норм, добро пожаловать в писательское сообщество.
"baseUrl": "src",
Тогда импорты будут выглядеть примерно вот так
import RouteLeaveGuard from 'components/service/RouteLeaveGuard';
import ConfirmDialog from 'components/ui/ConfirmDialog';
import { preventSubmit, scrollErrorIntoView } from 'helpers/forms/tools';
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 не понадобился.
Path aliases in React