Lynn «Кофеман»

Нет, не стоит.
Вы тупо будете слушать, как картавый мычащий Васян пересказывает какой-нибудь learnjavascript, пропуская половину тем, которые сам не понимает.
И таких видео - 90%.

async / await

/**
 * асинхрота с запросом. Возвращает Promise
 */
const doAsyncStuff = (urlIter, urlSite) => new Promise((resolve, reject) => {
  needle.get(urlIter, (err, result) => { // Сама асинхронная функция
    if (err) reject(err);
    $('.product-card__link')
      .each((i, val) => prodLink.push(urlSite + $(val).attr("href")));

    resolve();
  })
})

/**
 * Тот самый цикл
 * @param {number} quanPage число страниц
 */
const doStuff = async quanPage => {
  for(let i = 1; i <= quanPage; i++) {
    let urlIter = urlSite + i; // Ссылка, которая создается с каждой новой итерацией
    await doAsyncStuff(urlIter, urlSite); // Ждём-с!
  }
}

doStuff(10);

Демо:

Алгоритм:

1. ручкой пишем на бумаге первые несколько степеней 9
   
2. в голове появляется догадка
   

Насколько я понимаю, это скриншот вот отсюда https://learn.javascript.ru/map-set

Там подразумевается, что если использовать не Set, а обычный массив, то перед вставкой надо бы проверять, нет ли уже такого значения. И cделать это можно и при помощи find, и indexOf, и includes, и еще примерно десятком способов.


вариант с includes читается получше

makeArmy возвращяет массив функций
мы берем первый элемент массива и выполняем функцию

const army = makeArmy();

army[0](); //0

function makeArmy() {
	return [
		function () {
			return 0;
		},

		function () {
			return 1;
		}
	];
}

Когда говорят "оптимально" я спрашиваю "по какому критерию". Потому что беготня по массиву до середины оптимальна по памяти, но не факт что компилятор осилит правильно подстроить чтение и запись под ширину кэш-линий.
А уж про то, что обмен через xor или сложение-вычитание лучше - легенда тянется со времен машин, где не было инструкции xchg и этот фокус позволял обменять местами два регистра, не задействуя третий.

"Понятность" кода - это просто еще один критерий оптимальности, а уж когда какой выбирать - зависит от корпоративного стандарта написания кода.

Запись вида:

const methodName = 'bar';

const foo = {
  [methodName](message) {
    alert(message);
  }
}

аналогична записи:

const foo = {
  bar(message) {
    alert(message);
  }
}

Демо
Вычисляемые свойства
Symbol.toPrimitive

вангую: проблема в цветовой схеме терминала; вывод есть, но цвет такой же как у бэкграунда.

поздравляю, вы решили переизобрести браузер.

Согласно официальной документации package-lock.json предназначен быть в репозитории, чтобы все разработчики проекта работали с одним и тем же набором зависимостей.

Относительно того, что его не нужно включать в код библиотек - неправда:

• Во-первых, когда выполняется npm publish, package-lock.json автоматически исключается из опубликованного пакета (проверьте командой npm archive, например)
  
• А во-вторых, package-lock.json используется только в корне проекта. В зависимостях он игнорируется. То есть в директории node_modules/your-dependency он может присутствовать невозбранно.
  

Ответ на ваш вопрос: никогда не добавляйте package-lock.json в .gitignore