Как упростить импорт JavaScript модулей с помощью Node.js Subpath Imports

[AlexSpaizNet]

Никогда не понимал чем людям мешают ../../../

Они же там вверху, никому не мешают. Да и сразу видно откуда ноги растут, не нужно смотреть еще куда то...

Столько телодвижений что бы это все запустить. А если поломается, кто чинить будет =))

[synthema]

Разве @/components/Header.jsx не удобней чем ../../../../../Header.jsx?

Я был приятно удивлён, когда увидел в первый раз @/ в NextJS, --но как-то стало грустно, что никто из сеньоров не имплементировал это чудо в нашей компании--.

[AlexSpaizNet]

Удобней чем? Хорошему IDE пофиг как это выглядит. Все что нужно мне как девелоперу, это возможность кликнуть и перейти в файл + автокомплит IDE который заимпортит файл и поставит правильный путь сам.

Заниматься настройкой всего это чуда и потенциальные проблемы с этим в будущем не стоят потраченного времени.

И я понимаю почему синьоры этим не занимались. Потому что есть более серьезные проблемы четь удобство путей к файликам. А еще синьеры понимают что если что-то поломается, они будут это чинить...

P.S.

Если когда нибудь это будет из коробки, это другой разговор.

[dsrk_dev]

1. Нельзя сходу определить откуда именно импортируется файл

2. Нельзя копипастить код между файлами, ибо сменился уровень вложености файла и надо править импорты

3. Сложнее линтить импорты

[Senyaak]

1. Определять нужно не по пути, а по имени импортируемого

2. Обычно идешки сами правят такие вещи, поэтому копипасты работают

3. Да вроде как нет...

   По сути имя файла используется разработчиком только 1 раз, чтобы сказать что импортируется, потом на него нет смысла смотреть вообще никогда

[bubn0ff]

Благодарю, познавательно. Во всяком случае такие "алиасы" ещё не использовал, надо будет попробовать в тестовом режиме. В реальных проектах пока что не рискнул бы такое делать.

[difuks]

Спасибо огромное за статью! Всё получилось, но:

Как вы правильно отметили, в WebStorm существует проблема, которая решается добавлением алиаса в tsconfig.json

    "paths": {
      "#*": [
        "*"
      ]
    },

Но это приводит к проблемам, в случае использования монорепы с воркспейсами. Например, в воркспейсе @app/ui есть файл shared/utils.ts и в @app/main есть аналогичный файл shared/utils.ts

Тогда при выполнении tsc в @app/main мы получаем ошибку:

 Module '"#shared/utils"' has no exported member 'UIConfig'

В общем, проблемы из-за коллизий псевдонимов путей в двух воркспейсах. При удалении paths из tsconfig.json проблема пропадает, но автоимпорты и go to definition в IDE перестают работать корректно

[Nodge]

TypeScript умеет изолировать алиасы на уровне пакета в монорепе, если настроить Project References. Из минусов – приходится дублировать монорепные зависимости и в package.json, и в tsconfig.json.

[difuks]

Я смотрел в эту сторону. Мы используем tsc только для проверки типов (no-emit: true). Аналогично работе webpack-fork-ts-checker или vite-plugin-checker. К сожалению, project references не работают без физической сборки js/d.ts файлов

[Nodge]

У нас все то же самое в проекте :)

Пришли к вот такому:

• в редакторах кода сборка не требуется, language server собирает в памяти на лету

• для tsc настроили outDir в node_modules/.cache. Проверка типов выполняется чуть дольше из-за записи файлов на диск, но не критично.

• еще могут возникнуть проблемы с typescript-eslint, из коробки он тоже требует сборку. Решается включением параметра EXPERIMENTAL_useProjectService.

[difuks]

Спасибо! Попробуем. А по скорости сборки есть существенная разница?

[difuks]

Прошу прощения, вы уже ответили на этот вопрос. Ещё раз спасибо!