Dmitry Didenko

Enterprise разработка - это разработка, направленная на решение проблем бизнеса. В отличии от разработки для решения проблем конечных пользователей.

На самом деле нет каких-то зафиксированных принципиальных характеристик, которые присущи только EA. По-этому, в разговорной речи понятие "энтерпрайз" может значить весьма разные вещи. С одной стороны энтерпрайз - не про увлечение модой с переписыванием всего, как только появится новый тренд. Ибо это _дорого_, так как цена ошибки дорога. С другой стороны - совсем не обязательно, что это 20-летние технологии. Конкретный бизнес сам для себя выбирает модели развития и обновления стека технологий. С одной стороны - это сложность ПО, бизнес-логики. С другой - сложность понятие весьма относительное.

Но если все же пытаться выделить какие-то характерные черты, я бы назвал несколько:
* устойчивость к трендам (использование их, когда они пройдут стадию моды и перейдут к стадии заинтересованности крупными игроками, ибо никому не нужны технологии, которые через год умрут и их поддержка будет дорожать каждый день).
* сложная и непостоянная бизнес-логика, давление на нее из множества источников
* результат сложной переменчивой бизнес-логики в совокупности с длительным использованием продукта приводит к целям снижения стоимости поддержки за счет стоимости первоначальной разработки, производительности и потребляемых ресурсов. ООП, SOLID, Unit Test/TDD, DDD - все эти популярные буквы - последствия "энтерпрайза", когда мы готовы серьезно подходить к написанию кода для облегчения его последующего изменения.
* слабо заметный вклад конкретного программиста, проистекает из сложности ПО

Требования к программисту... ну я бы сказал, усидчивость, вдумчивость, исполнительность... хм, а что, в каких-то других областях другие требования к программистам? Хотя, конечно, в противоположность, можно назвать способ разработки "быстро-быстро и в продакшн". Но, к слову, такие ситуации могут и в энтерпрайзе возникнуть.

По-этому, стоит рассматривать не энтерпрайз/не энтерпрайз, а конкретные компании с конкретными требованиями и циклами разработки.

Нарисовать надо по пиксельной сетке, иллюстрирую:


Если дизайнер изначально об этом не думал, когда рисовал (точки поставлены наобум, либо используется не целочисленная величина обводки) - вы с этим ничего не сделаете.

На экранах повышенной плотности, к слову, эффект менее заметен (что не особо радует всех остальных).

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

Если у вас внешний пакет (иначе непонятно, причём тут `main` в `package.json`), и вам нужно сделать экспорт конкретного файла по "короткому" пути, то следует оформить так:

// package.json вашего пакета, допустим, "mypackage"

{
  "name": "mypackage",
  "exports": {
    ".": "./dist/index.js",
    "./whatever/": "./dist/whatever/non-index.js"
  } 
}

Важно: это минимальная версия, там есть тонкости относительно разного экспорта ESM, CJS и d.ts файлов, но тут такой вопрос не стоит.

Если у вас есть такой пакет, то в другом пакете, в который вы установили его как зависимость, вы можете импортировать по "короткому" пути:

// "Короткий" импорт, без него пришлось бы делать что-то вот такое:
// import { whatever } from 'mypackage/dist/whatever/non-index.js';

import { whatever } from 'mypackage/whatever';

---

Если речь идёт о том, чтобы использовать алиасы внутри одного проекта, то следует сконфигурировать алиасы в `vite.config.ts`, документация вот здесь, выглядеть будет примерно так:

// vite.config.ts

import { fileURLToPath, URL } from 'node:url';

export default defineConfig({
  resolve: {
    alias: [
      { find: '~components', replacement: fileURLToPath(new URL('./src/components', import.meta.url)) },
    ],
}),

И в `(js|ts)config.json`, при наличии, добавить:

{
  "compilerOptions": {
    "paths": {
      "~components/*": ["./src/components/*"]
    }
  }
}

Смешались в кучу кони, люди...
Давайте по порядку.

Должен ли UX/UI дизайнер знать компоненты таких фреймворков как React и Vue

Если команда разработчиков заранее знает, что будут использовать какой-нибудь набор готовых компонентов для работы (Vuetify, Material UI, etc), то дизайнер должен их знать и использовать как основу, дабы не плодить лишних сущностей, так как без боли эти компоненты можно разве что перекрашивать.

подготавливать макет прямо на React, но без логики

"Макет на React без логики" - это вёрстка.
И боже упаси, чтобы это делал дизайнер - с этим и большинство фронтов так себе справляется (во многом потому, что через 3 месяца работы над пет-проектом говорят "я уже хорошо знаю HTML и CSS, пошёл учить Реакт и получать ЗП в 200+", ха-ха).

не зная можно ли вообще реализовать такой календарь

Реализовать в принципе можно почти всё что угодно, вопрос кому оно нужно и кто готов за это платить.

но наверное какие-то основы, работу с NPM, CSS/SASS препроцессоры он должен знать?

Очень хорошо, когда дизайнер имеет представление о том, как результат его труда в дальнейшем будет реализован. Но с набором технологий вы сильно дали маху - это всё очень профильные вещи, которые толком изучить - отдельная профессия.

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

Вообще такое ощущение, что все вокруг просто на самом деле ничего толково делать не умеют, но пытаются себе цену добавить мнимым знанием кучи всего. Сфокусируйтесь на одном чём-нибудь.
Человеку, который делает гениальный дизайн, прощают всё - сложный характер, срывы сроков, никакую структуру файлов, Layer1-layer2 - и возвращаются к нему снова, потому что это профессионал в своём деле, и нет совершенно никакой нужды добавлять себе стоимость второстепенными навыками. Разве что самому интересно..

В идеале - да, по факту - оно того чаще всего не стоит, ниже объясню почему.
* Вообще, если у вас такой вопрос возникает, то вам оно, скорее всего, не нужно.

Основных целей две:

1. Автоматическое перестраивание макета в случае использования компонентов
   Вот есть у вас традиционная, любимая дизайнерская сущность "карточка".
   Она вынесена в компонент и используется на N страницах примерно N * 50 раз.
   Приходит клиент и говорит: хочу в карточку добавить внизу большую красную кнопку.
   Вы добавляете кнопку в компонент.
   Если и сам компонент, и все родители, где он используется, сделаны с помощью автолейаутов - на этом ваша работа заканчивается, все страницы выглядят как надо.
   
   Если автолейаутов нет, добро пожаловать либо в "руками передвинуть все экземпляры на всех страницах" (что нудно, скучно, а если клиент завтра передумает, то вообще лол), либо в "ну я вот тут на странице "Карточка v2" показал, как должно быть", что спустя какое-то время ведёт к бардаку на проекте, в котором невозможно найти концов.
   
2. Больше уверенности в том, что всё стоит ровненько
   Что выливается в то, что верстальщику над макетом работать приятнее - он видит автолейаут и он сразу уверен, что отступ между всеми элементами одинаковый.
   Скорее всего, получится сделать `pixel-perfect`, если заказчику это будет важно. А без автолейаутов у вас может быть ситуация, когда между одинаковыми элементами разный отступ.
   * Необязательно будет - можно быть внимательным, но дополнительная уверенность - это хорошо для всех. Технология страхует от ошибок.
   

Теперь о том, почему не стоит.

• Для того, чтобы автолейауты помогали процессу, а не мешали - у вас ещё до начала работы должно быть полное представление о том, что вы хотите в итоге получить.
  Если вы находитесь в процессе творческого поиска - рисуйте как рисуется. Как только кажется, что всё выглядит хорошо - подумайте над лейаутами.
  
• Когда нужно задизайнить сложный, составной компонент с разными вариантами - его реально нужно проектировать, по субъективным ощущениям это гораздо ближе к вёрстке, чем к дизайну - а это вообще другая профессия, и думать там надо по-другому.
  У меня, когда доводится рисовать, компоненты структурно получаются практически такие же, как они и на вёрстке потом будут - и это замечательно в долгосрочной перспективе - бардака меньше.
  Но я - в первую очередь технический специалист, а дизайнер не думает (и не должен думать) как верстальщик, и сделает немного не то и немного не так. Со стороны будет выглядеть чаще всего как "создал себе проблем на ровном месте".
  Кроме того, у этого есть минусы: компонент становится сложнее (порой - прям ощутимо), чем если просто внутри фрейма мышкой расставлять элементы. Это влияет на то, насколько легко другому человеку разобраться, что происходит и внести свои изменения.
  
• В фигме нет (пока нет) абсолютного позиционирования. Пока в ходу хак с фреймом ширины/высоты 0/0 - но это именно что хак, это увеличивает сложность и разработки, и поддержки. Сложные компоненты без этого не заворачиваются в автолейауты никак.
  
• Не очень опытных дизайнеров автолейауты серьёзно ограничивают в творчестве - дизайн получается... Ну, квадратный, что ли.
  
• Не все вещи возможно реализовать на автолейаутах
  

Во всём нужна мера. Должно быть удобно, быстро, надёжно и понятно команде.
А где эта мера - ну каждый ведь для себя решит, верно? :)

В ходе дальнейших изысканий определено, что реализовать это можно только с помощью написания своего расширения и вызовом не editor.action.insertSnippet, а метода своего расширения, который проверит предшествующий символ и вставит сниппет, если всё окей.

В моём представлении написание настолько мелких расширений - моветон, решил свою проблему добавлением нового сниппета, который по нажатию на "ctrl+#" вставит #{$var}, а "shift+3" (#) остаётся за обычным октоторпом.

Кейбиндинги, если кому понадобится:

{
  "key": "shift+[",
  "when": "editorTextFocus && resourceExtname == .scss || resourceExtname == .css",
  "command": "editor.action.insertSnippet",
  "args": {
    "snippet": " {\n\t${0}\n}"
  }
},
{
  "key": "ctrl+3",
  "when": "editorTextFocus && resourceExtname == .scss || resourceExtname == .css",
  "command": "editor.action.insertSnippet",
  "args": {
     "snippet": "#{\\$${1:var}}"
  }
}