Роман

Я обычно тупо проксирую nodejs через nginx, чтобы не париться, а с nginx certbot дружит из коробки.
Вдобавок он берёт на себя многое то, что иначе пришлось бы реализовывать отдельно в nodejs-приложении - логгирование, отдача статики, сжатие данных.

arguments.callee, но это свойство недоступно в strict mode. В частности, в модулях.

Ну, или просто дайте функции имя, чего жадничать-то : )

(function toster() {
  console.log(toster);
})();

Метод say лежит в прототипе экземпляра Sounds, а не в самом экземпляре.
Object.assign копирует только содержимое непосредственно объекта, не заглядывая в его прототип. Так мир устроен.

if (message.channel.id !== 'id_1_канала' && message.channel.id !== 'id_2_канала') return;

или

if (!["id_1_канала", "id_2_канала"].includes(message.channel.id)) return;

'url(' + (img ? img : superImg) + ')'
или
`url('${img ? img : superImg}')`

Вместо repaintPanel добавьте

colors.forEach(e=>{
  let img = new Image();
  img.src= e.img;
  img.onload = function(){
      e.isLoaded = true;
      if(colors.every(e1=>e1.isLoaded))        
        repaintPanel();
  }
});

P.S. А вообще реализация через setInterval просто ужас, сделайте один игровой цикл и используйте requestAnimationFrame или setTimeout на худой конец
Первое что попалось, ознакомтесь если понятия не имеете что это такое

const words = ['Азбука', 'Ананас', 'Зелень'];
const letters = 'аБ'.toLowerCase().split('');
const result = words.filter(
  (word) => {
    const lWord = word.toLowerCase();
    return letters.every((letter) => lWord.includes(letter))
  }
);
console.log(result);
// Array [ "Азбука" ]

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

Что-то вроде этого:

const arr = ['Hello', 'World', 'John Doe', 'Hakuna Matata', 'Mosakusa'];
let input = 'da' 
let arrInput = input.split(''); // ['d', 'a']
arr.filter(str => arrInput.every(char => str.includes(char))); // []
input = 'ao', arrInput = input.split('');
arr.filter(str => arrInput.every(char => str.includes(char))); // ['Mosakusa']

Прошу заметить, что это не самое оптимальное решение в плане оптимизации. Очень вероятно, что можно сделать лучше

if (even == 0){

= - оператор присваивания, == и === - операторы сравнения.

Никто не заставляет использовать docker, systemd, ansible и вообще какие угодно системы оркестрации и оптимизации. Необязательно делать шаблоны конфигов или кластерные конфигурации сервисов, необязательно использовать библиотеки настраиваемого логгирования, возиться с балансерами и реприцируемыми базами. Но люди это делают, значит, смысл всё-таки есть?

Опытный администратор не должен задавать вопрос "нужно ли это вообще?" и исходить из идей вида "любому специалисто в области DevOps нужно вот конкретно это и не нужно конкретно другое". Он должен сам понимать, в какой момент сложность его инфраструктуры достигает того состояния, при котором ей нужно то или иное усложнение. Не рассуждать о том, что консул вообще не нужен или остро необходим, а принять решение о том, что и когда ему нужно для решения практических задач. Прекрасно, что в современном мире существует множество инструментов, которые позволяют достаточно быстро делать различные полезные вещи.

Консул - это тоже инструмент. Вряд ли хоть кто-то использует его возможности целиком и полностью, тем более что никто не заставляет. Кому-то достаточно того, что у него все сервисы зарегистрированы в одном месте и из коробки имеют автоматическое DNS-имя вида NAME.service.consul. Кто-то использует kv-хранилище для хранения параметров, а кто-то хранит в нём секреты и целые конфиги, настраивает токены с различными acl и скрещивает всё это с consul-template. Вообще, необязательно использовать именно консул, есть и другие инструменты для подобных задач. Например, zk/etcd.

Консул чаще используют совсем не с ансиблом, а с инструментами оркестрации, в которых сервисы могут расширяться и сворачиваться, перезагружаться и мигрировать. Скажем, пусть у нас есть условный сервис rabbitmq на три ноды. Тогда у нас может быть три контейнера rabbitm{1..3}, при запуске они регистрируются в консуле скриптом запуска вместе с проверками, а далее consul отдаёт их все три в виде имени rabbitmq.service.consul. Если какой-то из них вдруг упадёт, consul оперативно это обнаружит и исключит из DNS проблемный узел. Если вдруг управляющий всем этим администратор или автоматическая система оркестрации посчитает нужным добавить новые узлы или перенести их куда-то ещё в кластере, то consul также отразит все нужные изменения. При этом использующее rabbitmq приложение должно будет знать только адрес rabbitmq.

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

от джуна хорошо ожидать каких-то пет-проектов, где можно посмотреть не что он сделал, а как. Если интересует максимально быстрое трудоустройство, то начать делать проекты, а не велосипеды. Стоит очень много уделить внимание структуре проекта