rPman

Приведенный код не сохраняет в формате csv, так как нет корректной обработки строковых полей, многострочных например.

Советую не изобретать паровоз, а воспользоваться какой-нибудь готовой библиотекой типа csv-writer (не проверял но заявлена поддержка по rfc)

Для параллельных тяжелых вычислений нужно использовать воркеры или к примеру модуль child_process

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

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

в документации по nodejs приведет сразу же пример простейшего веб сервера, ищи что то похожэее, смотри в каких файлах идет вызов и соответственно запускай этот код

p.s. есть практика размещать все необходимое для запуска приложения в настройках пакета, тогда запуск будет что то типа:

npm install
npm build
npm run-script start

Т.е. install установит и обновит зависимости проекта, build запустит скрипты подготовки и оптимизации (например webpack), в общем что указано разработчиками, ну и запуск run-script start

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

Что значит сверять, давать ответ есть/нет? слово это строка с любыми символами (пробелы, знаки препинания) или набор букв на каком то языке с игнорированием регистра и вспомогательных символов (встречаются в других языках), а кодировка у файла?

Если просто строка без учета всего иного, то читаешь файл в память fs.readFileSync(filePath, 'utf8'); где utf8 - ожидаемая кодировка файла. Наличие слова в этой строке можно простым регулярным выражением new RegExp(`\\b${targetWord}\\b`, 'gi') и методом regexp.test(строка_с_содержимым_файла). Соответственно fs подключить require('fs').

Если пользователь будет вводить что угодно (а не слово, например символы \ которые часть регулярного выражения), то можно ограничить его ввод дополнительным регулярным выражением, проверяя и ругаясь соответственно.

Добавь в ссылку время создания кода активации и огранич ее время жизни, т.е. лимит не на количество.

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

Очевидно, что cron-стайл не решит твою задачу, что самое грустное, задача на столько простая, что решать ее сторонними инструментами и библиотеками - странно.

Мне кажется мочь запилить свой time-task-execute сервис должен каждый программист, начинающий карьеру.

99% работы по созданию своего сервиса - это управление временными интервалами, т.е. способ, с которым пользователь управляет своими задачами и задает время. Т.е. нет никаких проблем, чтобы сделать приложение, читающее конфиг (текстовые файлы или база данных, не важно) и организующее набор слипов (кода строк 5-10 где то - ищем ближайшую задачу, которая должна быть выполнена, делаем sleep на этот интервал, исполняем задачу, повторить).

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

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

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

Поэтому ответ:
- по первой схеме сервер отправляет клиентам с периодичностью информацию об итоговом изменении уровня жизней.
- по второй схеме сервер отправляет клиентам команду "начинайте увеличивать жизнь со скоростью X до уровня Y" и клиенты это выполняют, запустив свой таймер.
Для контроля состояний сервер может периодически высылать хеш своего состояния чтобы клиенты могли его сравнить со своим, если они различаются значит в коде баг (например неверно обрабатывается лаги) и как минимум нужна повторная загрузка состояния с сервера

никак

electron это браузер, и в нем мало сделано чтобы этот браузер не был похож на хромиум (есть эксперименты делать на основе firefox, без разницы), соответственно что бы ты не делал, чтобы все работало в результате должен быть браузер с его профилем и файлами.

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

https://www.npmjs.com/package/websocket
смотри примеры client example

попробуй что тут написали

An alternative might be ( but more typing in the long run )

$ cd /media/sf_shared/myproject
$ mkdir /home/dan/myproject && npm install --prefix /home/dan/myproject
$ NODE_PATH=/home/dan/myproject/node_modules node index.js