Нытье про js тулинг

Иногда я напитываюсь огромных количеством ненависти к тому, как устроена вся “экосистема” фронтенда. Это просто дикий набор костылей, который работает просто на удаче.

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

В процессе обнаруживается что vite, будучи нацеленным в первую очередь на esm ругается на одну из зависимостей наших пакетов. Пакет A (библиотека компонентов) импортирует в себя пакет B(набор тулзов), а у него внутри некорректное поле main в package.json. Чтож, можно же поправить!

Идем в пакет B, видим что там уже всё поправлено - добавлено поле exports, которое имеет более высокий приоритет, и все сборщики (что вебпак, что vite) прекрасно с ним работают. Нужно просто обновить версию - и все будет отлично.

Идем, обновляем. Сборка проходит. Запускаем тесты - видим что теперь jest не понимает как с этим работать. Читаем внимательнее, понимаем что в библиотеке компонентов jest версии 26, а с полями exports jest научился работать только в 28.

Обновляем до 28 версии - видим 100+ ошибок о том, что теперь jest вроде как встречает неизвестный токен export в зависимости зависимости! Хотя казалось бы, мы же вроде поддержку esm должны были получить после обновления…

Смотрим в пакет на который ругается, видим что в его package.json написано такое:

  "main": "./dist/index.js",
  "exports": {
    ".": {
      "node": {
        "module": "./dist/esm-node/index.js",
        "require": "./dist/index.js",
        "import": "./wrapper.mjs"
      },
      "default": "./dist/esm-browser/index.js"
    },
    "./package.json": "./package.json"
  },

Ругается наш jest именно на esm-browser/index.js. Проверяем - руками в node_modules меняем default на ./dist/index.js - тесты идут.

Таак. И че делать? Наобум пробуем обновить jest еще дальше, на 29 версию, получаем полное расхождение всех снапшотов + проблемы с jsdom. Ок, не катит.

Вроде vitest есть! Он же совместим почти полностью по апи, и построен сразу с идеей нормальной работы с esm-модулями!

Пробуем перейти на него. Мигрируем код код-модом, это же не долго! Запускаем. Получаем кучу изменений, но вроде бы вполне вменяемых. yarn vitest… не, ну конечно оно не запустилось. Выясняется что window.computedStyle нет в jsdom! Это патчится в jest какими то костылями, но vitest логично решили что это не их дело - пусть пользователи сами разбираются.

Напоминаю, я просто хотел апнуть версию одной зависимости. Кажется переход на другой тестовый фреймворк для этого - слишком жирно.

Читаем внимательно то, как можно конфигурировать jest. Вроде в вебпаке можно было указывать поле в package, из которого должен браться resolution…

Такого апи нет, но можно написать свой резолвер! Пробираемся через дебри не очень подробной документации, смотрим как написаны другие резолверы, делаем свой. Отлавливаем баги, вроде все запускается.

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

Локально тесты проходят. Создаем пр, пушим нашу ветку. Тесты падают в ci. Понимаем что наш резолвер работает не совсем корректно. Потом вспоминаем что часть разработчиков вообще сидит на windows, и наш резолвер вообще не умеет работать с отличными от / разделителями. Может пойти и просто поправить зависимости в core-components?

Теперь все это напоминает чудесный отрывок из шоу “Malcolm in the middle “

https://youtu.be/UZFI-8D5uA?si=yzBwabQNHgtBYm9

Короче говоря - в такие моменты хочется просто забить на весь этот тулинг, esm/cjs, тесты и вообще всё что связано с инструментами.

Хочется писать в блокноте код на jquery, рисовать скруглённые уголки таблицами и заливать всё это на сервер через ftp. А не вот это вот все.