Александр Маджугин

Опережая ответ, бросай это неблагодарное дело)

youtube, лучше смотри после прочтения ответа

Думаю первые два пункта очевидны, но напишу
1. Устанавливаешь node.js
Через консоль
2. Устанавливаешь bitrix cli
npm install -g @bitrix/cli

Дальше судя по логике человека из видоса, если у тебя не SPA, а у тебя наверняка не SPA:
3. Создаешь экстеншен для vue (или другого) плагина, в консоли переходишь в папку /local/js/имя_модуля/
bitrix create
отвечаешь на вопросы, имя твоего экстеншена должно быть без точек

4. Переходишь в папку с экстеншеном, пишешь
npm init

5. Скачиваешь нужный плагин
npm i названиепакета
проверь что в package.json он добавился

6. В редакторе открываешь bundle.config.js в нем добавляешь

plugins: {
	resolve: true,
},

7. Открываешь файл в папке src, который создался через bitirx create, в нем все стираешь и пишешь import плагина, как пример

import React from 'react'

export {React}

8. В консоли (проверь что находишься в папке со своим экстеншеном , а не где-нибудь в корне, иначе ядро сбандлишь и будет плохо)
bitrix build

9. Смотришь bundle в папке dist, если все ок, там должен быть транспилированный код твоего плагина

Теперь можешь юзать через битриксовое api

\Bitrix\Main\UI\Extension::load("имя_модуля.имя_экстеншена")

import React from 'имя_модуля.имя_экстеншена';

loadExtension('имя_модуля.имя_экстеншена').then(() => {
    // Код который использует `main.loader`
});

P.S.
Сам я пробовал react устанавливать, но у него в файлах используются переменные окружения node.js и т.к. они не определены js валится, как с этим быть я не разобрался и поэтому забил, может с другими плагинами норм будет.

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

$files = [
  '1.file',
  '2.file',
];
$resultFile = 'result.file';
$res = fopen($resultFile,'a+');
foreach ($files as $file) {
  $f = fopen($file,'r');
  while (!feof($f)) {
    $contents = fread($f,8192);
    fputs($res,$contents);
  }
}

Окей, буду умничать, если нужно объединить файлы именно на php (лимит памяти, нельзя вызывать сторонние утилиты shell_exec и т.п.) то делать это придется по частям.

Читаем от файла сколько то килобайт в память, пишем столько же в результирующий, снова читаем кусочек... потом повторяем со вторым.

fopen
fread
fwrite
fclose

больше работы с отслеживанием граничных ситуаций (пустые или отсутствующие файлы или нехватка места)

use Bitrix\Main\ORM\Fields\Relations\Reference;
use Bitrix\Main\ORM\Query\Join;
use Bitrix\Iblock\ElementPropertyTable;

\Bitrix\Main\Loader::includeModule('sale');

$propertyId = 1;

$result = \Bitrix\Sale\Order::getList([
	'filter' => ['PROPERTIES.IBLOCK_PROPERTY_ID' => $propertyId, '!PROPERTIES.VALUE' => false],
	'select' => ['ID'],
	'runtime' => [
		new Reference(
			'PROPERTIES', ElementPropertyTable::class,
			Join::on('this.BASKET.PRODUCT_ID', 'ref.IBLOCK_ELEMENT_ID')
		)
	]
])->fetchAll();

print_r($result);

$propertyId свой укажи

Первое что нужно понять, таймер работает асинхронно, а значит будет выполнен после цикла.
Второе - let имеет блочную область видимости (переменная видна в том блоке, где была объявлена, при этом первый операнд for считается тем же блоком, что и тело цикла)
Третье - циклы создают новый скоуп на каждую итерацию (на каждой итерации будет свой let i, при условии что этот оператор внутри цикла)

Ну и еще, в Ваших примерах 1000 относится не к таймауту, это просто бесполезная операция, а таймаут получит значение по умолчанию - 0, думаю это не совсем то, что Вы ожидаете.

Еще один важный момент, функциональное выражение (а стрелочная функция - это тоже функциональное выражение) внутри цикла будет создавать по функции на каждой итерации цикла. Это очень плохо и по памяти и по производительности (такие функции еще и компилироваться и оптимизироваться будут раздельно). И если в случае с let внутри цикла функции хотя бы будут отличаться замыканием (каждая замкнет свою i), то в первом случае будет 5 абсолютно идентичных функций.
Тут можно очень хорошо показать себя, если помимо объяснения принципов работы вспомнить, что setTimeout умеет передавать аргументы в свой колбэк:

const f = i => {
  console.log(i);
};
for (let i = 0; i < 5; i++) {
  setTimeout(f, 1000, i);
}

Без ларавел - можно и нужно, только на vue(или чем ещё клиентском) - нельзя.
Вообще, паря, с твоим пониманием сетевых технологий вообще трогать деньги нельзя. Серьёзно, если ты даже клиент от сервера не отличаешь - перепоручи лучше профессионалам.

Важные данные обычно никогда не хранятся на клиенте, они передаются, используются и удаляются.

Есть ли какие-то ситуации, когда использование httpOnly сессионной куки нас защищает, а вот использование localStorage и sessionStorage уязвимо?

Если есть компроментация клиента, то никак не защищает. Единственное место, это где JS вообще в принципе не используется, т.е. клиенты с отключенным JS. Ну это как в рыцарских доспехах ходить по улице. Неудобно, но вроде как защищает от меча. Только с мечом уже давно не ходят, все больше с автоматами.

Теперь про токены. Токены в теории лучше всего держать не в localStorage, а в sessionStorage. Это хранилище переживает перезагрузки страниц и не расшарено между табами. Т.е. при открытии того же самого адреса в новом табе будет созданая новая сессия. Хранилище очищается при закрытии браузера и таба. Но это жутко неудобно, каждый раз логиниться. Поэтому здравая логика говорит об использовании localStorage, хотя если вы совсем отбитый, то можете хранить токен в сессионой куке.

Если вы прочли те статьи внимательно, то можно понять, что преимущества сессионных кук нивелируются неудобством их использования.
JWT Токены предназначены для микросервисной архитектуры. Т.е. у вас есть некоторый центр аутентификации, который выдает вам токен. Токен этот подписан относительно стойкой криптографией и постоянно ротируется.
Этот токен передается другим микросервисам, которые могут его верифицировать через публичные ключи (JWKS).
Т.е. если вы хотите, вы можете строить свои сервисы так, что они доверяют не только вашему центру аутентификации, но и гуглу с амазоном через OpenID. Есть ситуации, например когда вы хотите разрешить доступ к сервису сотрудникам другой компании. Например, когда такая компания огромна (десятки тысяч сотрудников). Они аутенфицируются у себя, а вы проверяете, что токен выпущен сервисом данной компании. Это не так сложно реализовать.
Реализация авторизации лежит на плечах каждого микросервиса и напрямую завязана на бизнес-логику. Как правило это некий внутренний микросервис, который интегрирован c middleware микросервиса.

node.isConnected

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

То что браузеры позволяют делать несколько элементов с одинаковым id не значит что это правильно. Идентификатор по определению должен быть уникальным.

Используйте другие атрибуты для этого