Хоч сигнали зараз і популярні в Front-End фреймворках і бібліотеках, але не бачу суперечності у використання їх на бекенді, як один з інструментів реактивного програмування. Вони незалежні від рендерингу. Але так, основні зацікавлені сторони — на стороні фронтенду.

Власне, в цьому й претензія до npm, що вони повільно розвиваються і не відповідають вимогам часу. Тільки зараз крім фронтенду і частина бек-енд сегменту на js від npm залежить

Так, все вірно. Дякую!

Кманда Deno теж працює над цією проблемою і уже зарелізили JSR, який є «розширенням» npm dou.ua/forums/topic/48111

Вони трохи іншу сторону npm хочуть «пофіксити» — пакетний реєстр. yarn, pnpm — це менеджери залежностей, які все одно використовують реєстр npm. Команда Volt незадоволена що npm зі сторони реєстру еволюціонує дуже повільно. Повільне впровадження ESM-модулів, складність публікування, проблеми з безпекою. Тут інтерв’ю піврічної давності іншого члена команди про це syntax.fm/...​ger-vlt-with-darcy-clarke

Vlt (Volt) www.vlt.sh

Правда, інформації поки мінімум)

Hi Corbin! Thank you for the comment. I’m sorry, it was the wrong assumption from the pricing section on the site. I have changed this information. It’s really cool and thank you for this great guide!

Тут відповіли що плануюють працювати з ком’юніті, але поки незрозуміло як це буде виглядати github.com/...​diia-setup-howto/issues/6

просто бездумно повторювали за відео)

До повної інтеграції потрібно ще дожити і не втратити країну) А це може статися, якщо не займатися «державництвом».

Яка кон’юнктура? Очікуєте путіна?

Ресурс вправі вводити правила, які вважає доцільними. Ваш вибір — дотримуватися цих правил, чи не користуватися ресурсом.

Вчора ще релізнули yarn 4.0 yarnpkg.com/blog/release/4.0

Може бути корисним:

t.me/qa_security/937
t.me/qa_security/1171

+

Погоджуюся з Сергієм, що «класичний» патерн декоратор і декоратори ECMAScript, це трохи різні речі і обидва концепти мають право на існування.

Дійсно, якщо вам не потрібно логувати інформацію у всіх випадках, то ES-декоратор вам не підходить. Тому тут залежить від конкретної ситуації.

Наведений вами приклад застосування патерну декоратор також має свої обмеження, адже для того щоб «обгортати» різні інстанси одним декоратором — потрібно, щоб ці інстанси реалізовували один інтерфейс. В свою чергу, ES-декоратор, наприклад методу, можна застосовувати до різних методів різних класів. Такий собі спосіб перевикористання логіки.

«Палка має два кінці» 🙂 Ті ж самі макаки можуть і на JS так код написати, що потім довго можна в рантаймі помилки виловлювати. Тому я за здоровий глузд і використання інструменту лише там, де він принесе більше користі ніж шкоди 😂

Фактично TypeScript є «superset» JavaScript і зберігає зворотню сумісність, додаючи зверху свої «фічі». Тому не бачу особливої проблеми.

context.name має тип string | symbol

Якщо context.name явно не привести до рядка, то буде помилка про те що неявне приведення symbol в string викличе помилку в рантаймі.

Так, більшість прикладів взяті з анонсу (але не всі 🙂), ну і це ж не дослівний переклад (але кого то цікавить 😂).

В будь-якому випадку, дякую за критику. Я це врахую.

+