Комментарии 24
А вместо слэша в регэкспах другой символ нельзя? sed умеет (доводилось пользоваться, чтобы не усложнять скрипты кучей эскейпов), может, и в js можно?
Upd: вроде если регеэкспы создавать через конструктор – эскейпить не надо.
Все проблемы можно решить используя
nodemon --loader ts-node/esm -e ts -q --no-warnings
Ну и вписать в tsconfig
"moduleResolution": "node",
"esModuleInterop": true,
Единственное, что пока нужно указывать в импортах расширения .js
Вы такой командой приложение и на проде планируете запускать?
Использую ts-node на проде(transpile only). Вообще отлично. Оверхед в виде +10сек на старт скрипта(и то речь про тяжелые вещи), который происходит только при выкате новой версии и +50Мб памяти вообще не волнует. Специально на выходных тестировал tsc против ts-node. Не стоит оно того.
Зато офигеть как удобно работать напрямую с TS файлами. Это при том, что у меня половина кода используется и на клиенте и на сервере. Чисто для сервера берите не задумываясь.
А ещё тесты сразу на TS (jest) - тоже удобно
Ну что ж, это ваш подход и вы имеете на него полное право)
Но я предпочитаю затаскивать в проект как можно меньше прослоек.
Хотя о чем это я. Ведь мой скрипт из buildtools и есть аналогичная прослойка. Правда у меня над ней есть контроль.
На самом деле им много кто пользуется, судя по репозиторию.
На счёт прослойки вы правы. Но я точно так же не смотрю что там сбилдилось в JS, так что получается аналогично. Просто транспиляция происходит на лету.
Современный JS это одни прослойки ))) Без них уже давно ничего не работает.
Да я сам им пользуюсь! При локальной разработке.
Но по поводу "не смотрю во что сбилдилось" вы абсолютно правы.
Так что получается сам тайпскрипт является такой нежелательной прослойкой.
От неё я правда пока отказаться не готов.
почему нет? данная команда просто заменяет встроенный лодер на тс
таким образом получаем небольшую задержку на этапе импортов, но потом нода работает с обычной скоростью (подробнее тут)
рядом можно разместить сборку обычным tsc ничего не меняя, однако в таком случае ломаются ссылочные импорты через # и придётся городить костыль
На самом деле я задал неправильный вопрос. Какой командой вы стартуете приложение на проде и отличается ли она от команды node это тема отдельной дискуссии.
ведь моя проблема не в том что я не могу заимпортить какие-то модули. с этим проблем нет.
раньше я использовал require и мог подгрузить пакет @nestjs/serve-staticвнутри блока if и делать это только при локальной разработке. сейчасмой мой новый классный импорт обязан быть на верхнем уровне файла и мне придётся переносить @nestjs/serve-staticиз дев в основные зависимости. Как эту проблему решает то что мы запускаем приложение с использованием ts-node лоадера?
ormconfig.js обязан быть ES6 модулем как и все остальные файлы в проекте. И теперь, когда я вызываю команду по генерации миграции, typeorm игнорирует данный конфиг и кладёт файл с новой миграцией в корень проекта вместо той папочки которая указана в конфиге. Как эту проблему решает то что мы запускаем приложение с использованием ts-node лоадера?
Извиняюсь, если в тексте статьи я недостаточно четко сформулировал проблемы.
Почему не использовать динамический импорт?
Нодемон вполне может работать и в продакшне
И да, статику не следует отдавать нодой, для этого есть nginx
А почему вы не используете бандлер? Он бы решил проблемы с импортами без всяких регулярных выражений.
Замечание резонное.
Наверно по инерции.
Я считаю в бандлерах для бэка нет необходимости - это для клиента важно сколько будет весить сборка и сколькими чанками она приедет. На бэке же я могу себе позволить повторить исходную файловую структуру. И даже проще потом разбираться будет.
Моя идея была следующая (возможно я на ней мало акцентировался) - раньше у меня всё "всего лишь" работало. Интересно, если я сейчас затащу в проект ES6 модули, продолжит ли у меня всё "всего лишь" работать?
Оказалось что нет. Нужно что-то с этим делать. Но что? Затаскивать в проект лишнюю зависимость, работу которой я не контролирую мне не хотелось (возможно вы заметили что у меня бзик по поводу уменьшения зависимостей). Так что наверно я просто не стал выходить из зоны комфорта))
ConfigModule.forRoot({
validationSchema: Joi.object({
PORT: Joi.number().required(),
JWT_SECRET: Joi.string().required(),
JWT_EXPIRATION_TIME: Joi.number().required(),
DB_URL: Joi.string().required(),
}),
isGlobal: true
})
Смотрел.
если вы в принципе про наличие валидации конфига, то она у меня есть - перед ретюрном есть вызов validateConfig(config). Что там происходит - в рамках данной статьи неважно.
А по поводу joi - после моего issue в опцииConfigModule
добавили параметр validate с кастомной функцией валидации. Раньше была только возможность передать validationSchema со схемой joi
Лично мне кажется странной идея затаскивать в проект ещё одну зависимость (которая за собой так же тянет кучу зависимостей) ради одного вызова при старте приложения, если у меня все дто-шки валидируются через class-validator
А какой профит у import перед require ?
Опуская декор - остаётся возможность
"частичного импорта" это жы так крутааа, не тянуть всю либу а только "нужные классы".
Но вот вам интересная мысль: что если плюнуть на "частичный импорт руками" и испортить все :
import * as kissmyass from '/zhopasruchkoy'
А потом запускать какую-нибудь приблуду к веб-паку которая будет включать в реальный бандл только реально импортируемые вещи ?
Импорт руками это такое же щасте как ручная подсветка кода или проставки парных скобок.
Но в итоге "частичный" импорт выливается а полотенце "import" ов, иногда просто идиотических размеров!!!
И тут вопрос а зачем тогда import если " import * " это и есть require !?
Буду искренне благодарен за предметное объяснение (без воды и пены) и да, аргумент "патамушта тайпскрипт" - не аргумент, тайпскриптеров итак скоро пойдут подъезды мыть чтобы искупить все то гавно которым они засрали мир современной веб-разработки.
И у меня сильное подозрение что весь этот исход на import - одно из таких говн
Я конечно понимаю что тришейкинг заботит очень многих. Но не меня, т.к. на стороне сервера размер бандла не является проблемой.
Но в целом вопросы, которые вы задаёте, возникают и у меня.
Вот я потратил некоторое количество усилий, поправил некоторое количество нестыковок, натянул сову на глобус, и теперь у меня ES6 модули!
А профит то какой?
Было прикольно этим заниматься, но на вопрос о профите надо найти ответ. Потому что этот вопрос, например, задаст команда, если ей предложить затащить это счастье на основной рабочий проект. А там уже кодовая база сильно больше и зависимости хитроумней. Так что для миграции нужно будет потратитьв разы больше усилий. И усилия эти обосновать пока не получается.
Так что личто я комментарий заплюсовал.
Откуда открыл ссылку только что убей не помню, но вот вместе с комментариями на тему статьи Gist Github ESM
Мой опыт перевода typescript проекта на ESM