Default import из ESM, а типы как у CommonJS

Лучше отдельный файл объявлений на каждое условие. Вложите types внутрь каждого условия, тогда формат определяется одним расширением, без оглядки на поле "type" пакета.

"exports": {
  ".": {
    "import": {
      "types": "./dist/index.d.mts",
      "default": "./dist/index.mjs"
    },
    "require": {
      "types": "./dist/index.d.cts",
      "default": "./dist/index.cjs"
    }
  }
}

В справочнике по модулям в handbook пример устроен с той же вложенностью.

Страшнее в нынешней схеме то, что ui.default() проходит проверку типов. Проверка типов знает только модуль, описанный в файле объявлений, а какой файл Node выберет при запуске, ей не видно. Подгоните код под неверные типы, и ошибка просто переедет во время выполнения.

Перевести весь пакет на ESM тоже нормально. Но если кто-то ещё ходит через require, его типам нужна отдельная забота.

Способ Tess чинит сторону ESM. Сборка выпускает index.d.mts и index.d.cts, а exports разбит по условиям. На ui( редактор молчит, default из автодополнения пропал, а --traceResolution показывает, что условие import ведёт к index.d.mts.

Но за другим условием надо следить. Если сборка просто копирует то же объявление в index.d.cts, вместе с export default, то старый скрипт .cts с import ui = require('@repo/ui') проходит проверку типов с ui.default(), а CJS-бандл кладёт функцию прямо в module.exports. Во время выполнения ui.default равен undefined. Исходная ошибка, только зеркально, на другом условии.

Объявлению для CJS нужна своя форма.

declare function ui(): string;
export = ui;

Так обе стороны сходятся. Правда, скрипт сборки теперь не копирует один файл объявлений, а пишет два разных, и это лишний шаг, с которым придётся жить.

Стоит проверить ещё две вещи.

Первое - порядок условий. В документации Node сказано, что "types" всегда должен идти первым, а условия сопоставляются в том порядке, в каком записаны в объекте. Сейчас у вас это соблюдено, но после разбиения по условиям "types" должен стоять первым и внутри каждого блока.

Во-вторых, проверьте, есть ли в tsconfig потребителя references. С project references модули из проекта по ссылке берутся из .d.ts, который этот проект собрал, а tsc --build сначала пересобирает устаревшие проекты в порядке зависимостей. Без ссылок компилятор может прочитать старый файл объявлений, оставшийся в dist, и никто этого не заметит.

Пусть зависимости в package.json и references описывают один и тот же граф, тогда такие проблемы вылезают рано, и обычно в виде ошибки сборки, а не странной картинки в редакторе.

Пользуются только соседние пакеты? Уберите CJS-сборку, второй файл объявлений уйдёт вместе с ней. Останется найти тот единственный скрипт, который всё ещё зовёт require.

jo_ren, ваше замечание про references попало в точку. В tsconfig потребителя не было ни одной ссылки. Поэтому сразу после первой правки package.json редактор ещё какое-то время показывал старый index.d.ts, а мне долго казалось, что неверна сама правка.

Порядок и так был правильный, так что не в нём дело. Ссылки добавлены, один прогон tsc --build, dist заполнился заново, и только тогда типы на экране совпали с правкой.