Жабысриптеры, привет) Я буду скидывать сюда ссылки на классные статьи про JavaScript и JavaScript библиотеки 💩

ИМХО, Kitze один из лучших спикеров прошедшего React Day Berlin. "Navigating the Hype-Driven Frontend Development World Without Going Insane" очень легкий и позитивный доклад. Возможно, доклад не сильно технический, но видно, что Kitze очень крутой жабаскриптер и все по делу.
Отличное видео, чтобы расслабиться в воскресенье :)
https://www.youtube.com/watch?v=QZ6aC6G0ufg

Много лет я писал на Perl и там огромное количество удобных библиотек для написания тестов. В случае с JS все не так хорошо и много лет использую mocha + chai, но недостатков у этих библиотек хватает.

Недавно нашел AVA и понял, что в JS тоже случаются замечательные вещи :)

AVA - это новый инструмент, который решает большинство этих проблем.
1. Не опирается на глобальную доступность тестовых утилит.
2. Позволяет запускать тесты параллельно.
3. Простой и удобный API и очень простая конфигурация (например, даже с mocha использовал qunit интерфейс. Имхо, более читабельны). В случае с AVA сетап всего очень прост.
4. Современный ES из коробки. Я могу писать тесты с использованием всех самых современных фич JS, включая import и тд. Что более важно, тестируемый код будет работать как есть (без транспайлинга). Это позволяет мне быть уверенным, что мой код работает на конкретной версии ноды.
5. Основные ассерты из коробки. Часто нужна только AVA и ничего больше.
6. Ну и поддержка TAP, как крассплатформеный формат репортинга для тестов. Кстати, TAP пришел из Perl, в Perl - это аутпут всех библиотек для тестирования :)

Перевел несколько своих библиотек на AVA (к примеру, тесты на AVA для LIVR js), результатом очень доволен.

AVA - https://www.npmjs.com/package/ava

В JavaScript не так давно добавили тип данных Symbol. Обычно говорят, что Symbol дает возможность хранить метаданные в объекте или возможность реализации условно приватных свойств объекта. Но есть и другая сторона, Symbol решает ряд проблем и безопасностью приложения.

Отличный пост от Дэна Абрамова на эту тему. Основная идея в том, что React узлы внутри представлены в виде JSON объектов. И код, который вы считаете безопасным <p>{message.text}</p>,
на самом деле, содержит XSS уязвимость. Если message.text содержит пользовательский ввод и мы рендерим React на сервере, то злоумышленик может вставить в message.text JSON объект, который описует любую React ноду. Для того, чтобы от этого защититься, в JSON объекте должно быть свойство $$typeof и Symbol в качестве значения. В таком случае, злоумышленик не сможет заранее предсказать Symbol.

Статья - https://overreacted.io/why-do-react-elements-have-typeof-property/

Еще отличный пример - это Sequalize. Для описания запроса раньше использовались строковые операторы

Post.findAll({
  where: { 'or': [{authorId: 12}, {authorId: 13}] }
});

сейчас это:

Post.findAll({
  where: { [Op.or]: [{authorId: 12}, {authorId: 13}] }
});

где Op.or это Symbol, что не позволяет злоумышленику так просто сделать ORM Injection.

Есть IoT платформа написанная на JS. Необходимо предоставить сторонним условно доверенным вендорам возможность писать сценарии и заливать их на наши устройства. То есть нужна безопасная песочница для выполнения сторонних скриптов. Есть различные варианты для решения этой задачи:

* Embedded lua. Но, поскольку плагины пишутся вендорами на JS, то и сценарии хочется писать на JS. И остается вопрос, можно ли создать с lua безопасную песочницу.
* Docker контейнеры. Они и так везде на проекте и для этой задачи они будут использоваться, но в контейнерах будет крутиться целый движок и все сценарии. Свой контейнер для каждого отдельного сценария слишком ресурсоёмко. Сценариев будет тысячи.
* Воркеры на WebAssembly - хороший вариант. То есть можно разрешить использовать в теории любой язык. Это отлично для Rust, по поводу JS (с тем же Duktape) не уверен.

В результате остановились на модуле vm2. Это как стандартный нодовский модуль vm, только для безопасного выполнения.

VM2 позволяет вам запустить чужой JavaScript код в безопасной пеcочнице. Вы можете разрешить доступ к определенным модулям или даже к опредленным методам определенных модулей. VM2 использует Proxy объекты, чтобы нельзя было вырваться из песочницы. Конечно любая такая песочница не даёт 100% гарантий, но в нашем случае это отличное решение, особенно в связке с docker.

Если вдруг будет стоять такая задача, рекомендую посмотреть на этот модуль.

VM2 - https://www.npmjs.com/package/vm2

Тред от Yehuda Katz про проблемы с кроссплатформенностью NodeJs модулей. Многие разработчики забивают на Windows. В этом нет большой проблемы, пока ты не публикуешь свой модуль на NPM.

Яхуда озвучивает 2 основные проблемы при работе под Windows:
1. Практически каждый package.json содержит команды в секции scripts, которые не работают в Windows. Основная причина - использование && и другого bash синтаксиса. От себя добавлю, часто вижу, что устанавливаются переменные окружения без использования crossenv, к примеру.
2. Это пути на файловой системе. Разработчики ожидают, что разделитель "/" - это валидный разделитель в Windows разделитель "\" ("\\"). Это создает ряд багов связанных с обработкой путей (например, когда мы обабатываем пути регулярками и тд).

Как делать правильно, можно найти в треде
https://twitter.com/wycats/status/1090307478254829569

Делайте свои модули кроссплатформенными, Micsrosoft сделала же VSCode под Linux и Mac :)

В догонку к позавчерашнему сообщению про vm статья о том, как Cloudflare начала использовать изоляты V8 для serverless вычислений. Идея дать возможность пользователям заливать свой код и выполнять его в безопасной песочнице (по примеру AWS Lambda или Google Cloud Functions)

Что мы имеем, в сравнение с классическим подходом, когда лямбды крутятся в docker контейнерах:
1. Холодный старт 5 ms, вместо от 500ms.
2. Потребление памяти 3mb вместо минимальных 35mb необходимых при механизме с контейнерами.
3. Стоимость в 3 раза ниже, чем AWS Lambda. Правда код нужно писать на жабаскрипте :)

СТАТЬЯ: https://blog.cloudflare.com/cloud-computing-without-containers/

После прочтения поста возникает вопрос, что такое "Isolate"? В интернете практически нет информации. Можно найти, что это deprecated фича, но на самом деле это не так.
Если посмотреть в исходники NodeJs, то можно увидеть, NodeJs workers используют изоляты -
https://github.com/nodejs/node/blob/master/src/node_worker.cc , а поверх node_worker, в свою очередь, построены новые worker_threads.

Isolate - это, по сути, отдельный экземпляр V8, со своим состоянием. Важно не перепутать:
1. Изоляты это фича v8, а не nodejs. worker_threads и тот же vm - это уже модули nodejs.
2. Cloudflare не использует NodeJs, а использует именно v8 (и изоляты).

Многие спрашивают про Test Coverage, каким он должен быть? Нужно ли стремится к 100% покрытию кода тестами?

Основная проблема, что уровень покрытия кода тестами ничего не говорит о качестве тестов. Помню мне рассказывали историю, когда покрытие было недостаточным и не могли принять реквест от разработчика. Разработчик не долго думая добавил просто вызовы функций в тесты (без проверки результата), чтобы увеличить покрытие до требуего уровня :).

Если вы стремитесь к 100% покрытию, то скорее всего тратите время не на то, что действительно важно (покрыть более сложные сценарии или граничные случаи). Главный критерий достаточного количества тестов - это количество багов на продакшене и насколько вы боитесь вносить изменения в код в связи с ожиданием дополнительных багов на продакшене.

Нужно ли использовать test coverage? Да, мы используем по следующим причинам:
1. Test coverage не позволяет быть увереным в наличие хороших тестов, но низкий test coverage явно говорит об отсутствии тестов вообще. Для бекенда для нас 80% покрытия всегда достаточно. С nyc (istanbul) отслеживать покрытие очень легко. Для фронтенда у нас нет требований по покрытию.
2. Поиск мертвых кусков кода. Про это в статье не говорится, но при помощи анализа покрытия это очень удобно делать. nyc (istanbul) позволяет в качестве репортера указать html и вы очень легко можете найти код, который никогда не вызывается и никогда не будет вызываться. Поиск мертвых кусков кода сложно переоценить. Часто этого кода бывает много и он сильно мешает потом новым разработчикам разбираться в проекте.
3. Поиск подсистем, которые вообще не покрыты тестами. Бывают ситуации, когда просто не написали тесты к какой-то функциональности по какой-то причине.

Более детально про покрытие кода тестами можно почитать у Мартина Фаулера в статье "Test Coverage" https://martinfowler.com/bliki/TestCoverage.html

Статья уже старая, но вопрос актуальный :)