S
Felix
Прикольно, надо бы почаще заглядывать в доку ноды
и в твиттер [ноды]
https://twitter.com/MylesBorins/status/1329163754639155201
Size: a a a
2020 December 18
S
VK
Felix
Нужно ли для бэка юзать вебпак ? Или это бессмысленно
Для чего? На сервере не важен размер бандла и кроссбраузерность
EP
То что хранить схему можно в json’е это очевидно, не понятно как именно сделать её общей, если у нас репозитории бэка и фронта разделены например
VK
То что хранить схему можно в json’е это очевидно, не понятно как именно сделать её общей, если у нас репозитории бэка и фронта разделены например
Вынести в библиотеку, есть всякие решения с кодогенерацией
Но у меня с такими решениями практического опыта нет, я такое писал только в рамках монорепы
Но у меня с такими решениями практического опыта нет, я такое писал только в рамках монорепы
EP
Без флага уже давно работает
Вас чё вообще чтоли никого не смущает что надо ставить расширение .mjs или type: module?
EP
Это же полный зашквар и очевидно что сборка на вебпаке лучше, просто import и поехали
EP
Оно станет хорошо только тогда когда разрешат без .mjs, и type: module станет опциональным в package.json
И
То что хранить схему можно в json’е это очевидно, не понятно как именно сделать её общей, если у нас репозитории бэка и фронта разделены например
Запрашивать по сети, например
И
Вас чё вообще чтоли никого не смущает что надо ставить расширение .mjs или type: module?
Зато время сборки 0 минут 0 секунд
꧁岡
Это же полный зашквар и очевидно что сборка на вебпаке лучше, просто import и поехали
ты знаешь что такое легаси?
EP
Зато время сборки 0 минут 0 секунд
С этим конечно не поспоришь. Но с раширениями ведь тоже жить не получится? Мы же не будем писать .mjsx и .mtsx?
И ещё кстати очень нелогично ставить type: module у типичного приватного npm-пакета фронта, который вообще не используется как модуль, то есть это нарушение логики
И ещё кстати очень нелогично ставить type: module у типичного приватного npm-пакета фронта, который вообще не используется как модуль, то есть это нарушение логики
EP
ты знаешь что такое легаси?
Ну это само собой. Но на самом деле конкретно с одних импортов мигрировать на другие мне кажется это не такая большая проблема
S
Оно станет хорошо только тогда когда разрешат без .mjs, и type: module станет опциональным в package.json
welcome to the deno club buddy
VK
Это же полный зашквар и очевидно что сборка на вебпаке лучше, просто import и поехали
Мне вот не очевидно чем притягивание сложного инструмента туда, где он не нужен, лучше
꧁岡
С этим конечно не поспоришь. Но с раширениями ведь тоже жить не получится? Мы же не будем писать .mjsx и .mtsx?
И ещё кстати очень нелогично ставить type: module у типичного приватного npm-пакета фронта, который вообще не используется как модуль, то есть это нарушение логики
И ещё кстати очень нелогично ставить type: module у типичного приватного npm-пакета фронта, который вообще не используется как модуль, то есть это нарушение логики
ты собрался jsx файлы в ноде импортить?
шо?
шо?
꧁岡
Ну это само собой. Но на самом деле конкретно с одних импортов мигрировать на другие мне кажется это не такая большая проблема
проблема то не большая, но commonjs не совместим с esm полностью, так что движку нужно знать как обрабатывать твой пакет из 2013 года чтобы он работал в ноде с включенным esm
EP
ты собрался jsx файлы в ноде импортить?
шо?
шо?
Нет ну с jsx конечно вариантов нет, только вебпак
И
С этим конечно не поспоришь. Но с раширениями ведь тоже жить не получится? Мы же не будем писать .mjsx и .mtsx?
И ещё кстати очень нелогично ставить type: module у типичного приватного npm-пакета фронта, который вообще не используется как модуль, то есть это нарушение логики
И ещё кстати очень нелогично ставить type: module у типичного приватного npm-пакета фронта, который вообще не используется как модуль, то есть это нарушение логики
jsx ничего общего с es не имеет. И обрабатываться без специального бабель-плагина никак не может
И
Нет ну с jsx конечно вариантов нет, только вебпак
Parcel, rollup, snowpack...