вы невнимательно читали статью либо коментарии на проде статика отдается при помощи nginx а при локальной разработке, чтобы поднимать меньше контейнеров динамически добавляется ещё один nest.js модуль для раздачи статики
Я конечно понимаю что тришейкинг заботит очень многих. Но не меня, т.к. на стороне сервера размер бандла не является проблемой.
Но в целом вопросы, которые вы задаёте, возникают и у меня. Вот я потратил некоторое количество усилий, поправил некоторое количество нестыковок, натянул сову на глобус, и теперь у меня ES6 модули! А профит то какой?
Было прикольно этим заниматься, но на вопрос о профите надо найти ответ. Потому что этот вопрос, например, задаст команда, если ей предложить затащить это счастье на основной рабочий проект. А там уже кодовая база сильно больше и зависимости хитроумней. Так что для миграции нужно будет потратитьв разы больше усилий. И усилия эти обосновать пока не получается.
На самом деле я задал неправильный вопрос. Какой командой вы стартуете приложение на проде и отличается ли она от команды node это тема отдельной дискуссии.
ведь моя проблема не в том что я не могу заимпортить какие-то модули. с этим проблем нет. раньше я использовал require и мог подгрузить пакет @nestjs/serve-staticвнутри блока if и делать это только при локальной разработке. сейчасмой мой новый классный импорт обязан быть на верхнем уровне файла и мне придётся переносить @nestjs/serve-staticиз дев в основные зависимости. Как эту проблему решает то что мы запускаем приложение с использованием ts-node лоадера?
ormconfig.js обязан быть ES6 модулем как и все остальные файлы в проекте. И теперь, когда я вызываю команду по генерации миграции, typeorm игнорирует данный конфиг и кладёт файл с новой миграцией в корень проекта вместо той папочки которая указана в конфиге. Как эту проблему решает то что мы запускаем приложение с использованием ts-node лоадера?
Извиняюсь, если в тексте статьи я недостаточно четко сформулировал проблемы.
Замечание резонное. Наверно по инерции. Я считаю в бандлерах для бэка нет необходимости - это для клиента важно сколько будет весить сборка и сколькими чанками она приедет. На бэке же я могу себе позволить повторить исходную файловую структуру. И даже проще потом разбираться будет.
Моя идея была следующая (возможно я на ней мало акцентировался) - раньше у меня всё "всего лишь" работало. Интересно, если я сейчас затащу в проект ES6 модули, продолжит ли у меня всё "всего лишь" работать?
Оказалось что нет. Нужно что-то с этим делать. Но что? Затаскивать в проект лишнюю зависимость, работу которой я не контролирую мне не хотелось (возможно вы заметили что у меня бзик по поводу уменьшения зависимостей). Так что наверно я просто не стал выходить из зоны комфорта))
Смотрел. если вы в принципе про наличие валидации конфига, то она у меня есть - перед ретюрном есть вызов validateConfig(config). Что там происходит - в рамках данной статьи неважно.
А по поводу joi - после моего issue в опцииConfigModule добавили параметр validate с кастомной функцией валидации. Раньше была только возможность передать validationSchema со схемой joi
Лично мне кажется странной идея затаскивать в проект ещё одну зависимость (которая за собой так же тянет кучу зависимостей) ради одного вызова при старте приложения, если у меня все дто-шки валидируются через class-validator
Да я сам им пользуюсь! При локальной разработке. Но по поводу "не смотрю во что сбилдилось" вы абсолютно правы. Так что получается сам тайпскрипт является такой нежелательной прослойкой. От неё я правда пока отказаться не готов.
Ну что ж, это ваш подход и вы имеете на него полное право) Но я предпочитаю затаскивать в проект как можно меньше прослоек. Хотя о чем это я. Ведь мой скрипт из buildtools и есть аналогичная прослойка. Правда у меня над ней есть контроль.
Интересно было бы услышать мнение человека который детально работал с обоими фреймворками. Лупбэк я трогал очень поверхностно. Но кажется лупбэк не нужен т.к. они опоздали
Интересный материал, спасибо!
красавчик.
спасибо!
Весьма интересно, спасибо.
А можно ссылку на статью python разработчика который пришел со списком из 22 вопросов?
вы невнимательно читали статью либо коментарии
на проде статика отдается при помощи nginx
а при локальной разработке, чтобы поднимать меньше контейнеров
динамически добавляется ещё один nest.js модуль для раздачи статики
Просто интересно было бы услышать ваше мнение)
А чем вам ts так не угодил?
Я конечно понимаю что тришейкинг заботит очень многих. Но не меня, т.к. на стороне сервера размер бандла не является проблемой.
Но в целом вопросы, которые вы задаёте, возникают и у меня.
Вот я потратил некоторое количество усилий, поправил некоторое количество нестыковок, натянул сову на глобус, и теперь у меня ES6 модули!
А профит то какой?
Было прикольно этим заниматься, но на вопрос о профите надо найти ответ. Потому что этот вопрос, например, задаст команда, если ей предложить затащить это счастье на основной рабочий проект. А там уже кодовая база сильно больше и зависимости хитроумней. Так что для миграции нужно будет потратитьв разы больше усилий. И усилия эти обосновать пока не получается.
Так что личто я комментарий заплюсовал.
как полезно бывает взглянуть на проблему незамыленным глазом.
динамический импорт хорошо подходит, спасибо!
На самом деле я задал неправильный вопрос. Какой командой вы стартуете приложение на проде и отличается ли она от команды node это тема отдельной дискуссии.
ведь моя проблема не в том что я не могу заимпортить какие-то модули. с этим проблем нет.
раньше я использовал require и мог подгрузить пакет @nestjs/serve-staticвнутри блока if и делать это только при локальной разработке. сейчасмой мой новый классный импорт обязан быть на верхнем уровне файла и мне придётся переносить @nestjs/serve-staticиз дев в основные зависимости. Как эту проблему решает то что мы запускаем приложение с использованием ts-node лоадера?
ormconfig.js обязан быть ES6 модулем как и все остальные файлы в проекте. И теперь, когда я вызываю команду по генерации миграции, typeorm игнорирует данный конфиг и кладёт файл с новой миграцией в корень проекта вместо той папочки которая указана в конфиге. Как эту проблему решает то что мы запускаем приложение с использованием ts-node лоадера?
Извиняюсь, если в тексте статьи я недостаточно четко сформулировал проблемы.
Замечание резонное.
Наверно по инерции.
Я считаю в бандлерах для бэка нет необходимости - это для клиента важно сколько будет весить сборка и сколькими чанками она приедет. На бэке же я могу себе позволить повторить исходную файловую структуру. И даже проще потом разбираться будет.
Моя идея была следующая (возможно я на ней мало акцентировался) - раньше у меня всё "всего лишь" работало. Интересно, если я сейчас затащу в проект ES6 модули, продолжит ли у меня всё "всего лишь" работать?
Оказалось что нет. Нужно что-то с этим делать. Но что? Затаскивать в проект лишнюю зависимость, работу которой я не контролирую мне не хотелось (возможно вы заметили что у меня бзик по поводу уменьшения зависимостей). Так что наверно я просто не стал выходить из зоны комфорта))
Смотрел.
если вы в принципе про наличие валидации конфига, то она у меня есть - перед ретюрном есть вызов validateConfig(config). Что там происходит - в рамках данной статьи неважно.
А по поводу joi - после моего issue в опции
ConfigModuleдобавили параметр validate с кастомной функцией валидации. Раньше была только возможность передать validationSchema со схемой joiЛично мне кажется странной идея затаскивать в проект ещё одну зависимость (которая за собой так же тянет кучу зависимостей) ради одного вызова при старте приложения, если у меня все дто-шки валидируются через class-validator
Да я сам им пользуюсь! При локальной разработке.
Но по поводу "не смотрю во что сбилдилось" вы абсолютно правы.
Так что получается сам тайпскрипт является такой нежелательной прослойкой.
От неё я правда пока отказаться не готов.
Ну что ж, это ваш подход и вы имеете на него полное право)
Но я предпочитаю затаскивать в проект как можно меньше прослоек.
Хотя о чем это я. Ведь мой скрипт из buildtools и есть аналогичная прослойка. Правда у меня над ней есть контроль.
Вы такой командой приложение и на проде планируете запускать?
А ваш продукт как называется?
Интересно было бы услышать мнение человека который детально работал с обоими фреймворками. Лупбэк я трогал очень поверхностно. Но кажется лупбэк не нужен т.к. они опоздали
Статья очень своевременная ;)
С platform-agnostic разработчики конечно капельку лукавят.
Но я знаю несколько примеров рабочих проектов (и все мои петы), которые используют fastify адаптер
Тот кто говорит, что это проще чем отнять конфетку у младенца, никогда не пробовал отнять конфетку у младенца ;) (с)
На мой взгляд именование переменных тоже входит в понятие качества кода. Но проверить это линтером невозможно.
Хотя конечно то о чем вы говорите - совершенно верно.
Мог бы - лайкнул бы )