VolgaVolga

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

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

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

Рекурсия есть:

const sum = data =>
  Array.isArray(data)
    ? data.reduce((acc, n) => acc + sum(n), 0)
    : (+data || 0);

Рекурсии нет:

function sum(data) {
  let result = 0;

  for (const stack = [ data ]; stack.length;) {
    const n = stack.pop();
    if (n instanceof Array) {
      stack.push(...n);
    } else {
      result += +n || 0;
    }
  }

  return result;
}

Здесь, конечно, будет складываться всё, что можно сложить. Т.е., не только собственно числа, но и всё, что может быть сведено к числу, например true, '0xBB', { valueOf: () => 666 } и т.д.

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

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

WIP
(Work in progress)

У вас классическая проблема обработки пользовательского ввода. Решается она по-разному в зависимости от контекста, в котором используются данные. Так как вы не указываете контекст, то и ответ будет соответствующе широким.

1. Запрос первоначально поступает в node.js (конкретно в движок v8, отвечающий за сетевое взаимодействие). Здесь возможны уязвимости, при которых специальным образом сформированный запрос может привести к отказу в обслуживании (DoS), несанкционированному доступу к памяти (вспоминается эпичнейшая уязвимость heartbleed) и иным спецэффектам.

2. Далее запрос поступает в express, где он парсится и преобразовывается в объект req. Здесь так же могут быть уязвимости, эксплуатируемые путем отправки специально сформированного запроса.

Пункты 1 и 2 исполняются до вашего кода, поэтому всё что вы можете здесь поделать - это вовремя обновлять софт и библиотеки.

3. Далее ваш код занимается обработкой данных. Важный момент в этом - санация и валидация данных.

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

Валидация - это проверка данных на корректность. Например, вы ожидаете номер телефона в поле phone. После санации останется проверить, что длина номера не нулевая и не больше 15.

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

Либо если данные будут вставляться в базу данных, то необходимо экранировать данные (либо вставлять данные через подготовленные запросы) чтобы не получить SQL injection уязвимость.

Вот тут как раз и появляется зависимость от контекста. В контексте базы данных - один способ экранирования. В контексте json - другой. В контексте HTML (при выводе данных пользователю) - третий. В ещё каком-нибудь другом контексте будут свои способы обезопасить данные.

Если рассматривать конкретно пароль, то с ним всё просто. Как правило, пароли не хранятся на сервере в открытом виде и предварительно подвергаются преобразованию в криптографически стойкий хеш (например, argon2 или scrypt). Сам хеш уже имеет фиксированный размер и известный набор символов. Поэтому санировать пароль не нужно, а при валидации просто проверить минимально допустимую длину, несовпадение с логином, email и может ещё какие-нибудь проверки, навязанные бизнесом или применяемыми стандартами.

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