Pull to refresh

Comments 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 это одни прослойки ))) Без них уже давно ничего не работает.

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

Deno ещё смотрел. Но они чёт слишком радикально отрезали «старые» возможности и там половина npm не работает, судя по докам.

почему нет? данная команда просто заменяет встроенный лодер на тс

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

рядом можно разместить сборку обычным tsc ничего не меняя, однако в таком случае ломаются ссылочные импорты через # и придётся городить костыль

На самом деле я задал неправильный вопрос. Какой командой вы стартуете приложение на проде и отличается ли она от команды node это тема отдельной дискуссии.

ведь моя проблема не в том что я не могу заимпортить какие-то модули. с этим проблем нет.
раньше я использовал require и мог подгрузить пакет @nestjs/serve-staticвнутри блока if и делать это только при локальной разработке. сейчасмой мой новый классный импорт обязан быть на верхнем уровне файла и мне придётся переносить @nestjs/serve-staticиз дев в основные зависимости. Как эту проблему решает то что мы запускаем приложение с использованием ts-node лоадера?

ormconfig.js обязан быть ES6 модулем как и все остальные файлы в проекте. И теперь, когда я вызываю команду по генерации миграции, typeorm игнорирует данный конфиг и кладёт файл с новой миграцией в корень проекта вместо той папочки которая указана в конфиге. Как эту проблему решает то что мы запускаем приложение с использованием ts-node лоадера?

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

как полезно бывает взглянуть на проблему незамыленным глазом.
динамический импорт хорошо подходит, спасибо!

Нодемон вполне может работать и в продакшне

И да, статику не следует отдавать нодой, для этого есть nginx

вы невнимательно читали статью либо коментарии
на проде статика отдается при помощи nginx
а при локальной разработке, чтобы поднимать меньше контейнеров
динамически добавляется ещё один nest.js модуль для раздачи статики

действительно, не вникал в суть

А почему вы не используете бандлер? Он бы решил проблемы с импортами без всяких регулярных выражений.

Замечание резонное.
Наверно по инерции.
Я считаю в бандлерах для бэка нет необходимости - это для клиента важно сколько будет весить сборка и сколькими чанками она приедет. На бэке же я могу себе позволить повторить исходную файловую структуру. И даже проще потом разбираться будет.

Моя идея была следующая (возможно я на ней мало акцентировался) - раньше у меня всё "всего лишь" работало. Интересно, если я сейчас затащу в проект ES6 модули, продолжит ли у меня всё "всего лишь" работать?

Оказалось что нет. Нужно что-то с этим делать. Но что? Затаскивать в проект лишнюю зависимость, работу которой я не контролирую мне не хотелось (возможно вы заметили что у меня бзик по поводу уменьшения зависимостей). Так что наверно я просто не стал выходить из зоны комфорта))

А вы смотрели в сторону joi и @nestjs/config для конфига?

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 - одно из таких говн

Просто интересно было бы услышать ваше мнение)
А чем вам ts так не угодил?

Я конечно понимаю что тришейкинг заботит очень многих. Но не меня, т.к. на стороне сервера размер бандла не является проблемой.

Но в целом вопросы, которые вы задаёте, возникают и у меня.
Вот я потратил некоторое количество усилий, поправил некоторое количество нестыковок, натянул сову на глобус, и теперь у меня ES6 модули!
А профит то какой?

Было прикольно этим заниматься, но на вопрос о профите надо найти ответ. Потому что этот вопрос, например, задаст команда, если ей предложить затащить это счастье на основной рабочий проект. А там уже кодовая база сильно больше и зависимости хитроумней. Так что для миграции нужно будет потратитьв разы больше усилий. И усилия эти обосновать пока не получается.

Так что личто я комментарий заплюсовал.

Откуда открыл ссылку только что убей не помню, но вот вместе с комментариями на тему статьи Gist Github ESM

Sign up to leave a comment.

Articles