Дмитрий Беляев

git config --global --get user.name
git config --global --get user.email

С аккаунтом github это никак не связано, все хранится локально у Вас на компе

Глобальные конфиги лежат в файле $HOME/.gitconfig
Локальные - в ближайшей папке .git вверх по дереву

https://git-scm.com/book/ru/v2

То что у Вас в полях created и viewed вполне можно отдать в конструктор Date, а даты уже можно сравнивать между собой

console.log(new Date("2020-05-22 16:24:16")); // работает

Дальше, последний created, тут нужно уточнение:
Если массив messages всегда упорядочен по полю created, как и в примере, то можно просто брать последний элемент массива и работать с ним:

const lastMessage = messages[messages.length - 1];
console.log(lastMessage);

Если такой гарантии нет, то нужно искать максимум:

const lastMessage = messages.reduce(([maxDate, maxMessage], currentMassage) => {
  const currentDate = new Date(currentMassage.created);
  if(currentDate > maxDate) {
    return [currentDate, currentMassage];
  }
  return [maxDate, maxMessage];
}, [-Infinity, null])[1];
console.log(lastMessage);

Ну а если с этим разберетесь, то с последним пунктом у Вас уже не должно быть проблем, тут все аналогично

В js все объект, что не является примитивом (простые объекты, экземпляры классов, массивы, Map, Set, функции).
Так что да, Map это объект.
А вот массивом он не является, ибоArray.isArray(new Map()) // false

Здесь есть вот такая штука [[Entries]]. А entries возвращает массив свойств объекта

Вообще-то entries возвращает итератор. Итератор - это тоже не массив.

Что делать если размер запроса больше чем размер буфера?

Читать в цикле. read вообще не гарантирует, что заполнит буфер полностью, но больше его размера он точно за раз не прочитает. А еще он возвращает io::Result<usize>, в котором сообщает, сколько реально байт было прочитано.

1.1) Нужно будет читать пока не найдется CRLF в буфере ?

Пока read не вернет Ok(0), ну или ошибку. Хотя с ошибкой не все так однозначно, согласно доке может вылететь Err(io::ErrorKind::Interrupted) при котором стоит повторить попытку чтения. Вообще CRLF будет после каждого заголовка, а когда заголовки закончатся будет 2 CRLF подряд, а потом еще может быть тело запроса, а может и не быть.

1.2) для этого мне нужно пройтись по буферу и искать CRLF . если его нет то очистить буфер и продолжать читать ?

нет, нужно распарсить то что пришло, куда-то сохранить, а потом продолжить чтение.

2) Как отделять один http запрос от другого ?

Если у нас не keep-alive, то каждый запрос будет в отдельном соединении, но keep-alive наступает только если обе стороны прислали заголовок Connection: keep-alive Можете сделать по простому, и отвечать с заголовком Connection: close, все равно в учебном проекте производительность у Вас будет никакая. Но если хотите все же заморочиться, то правило тоже не сложное - следующий запрос начинается в следующем же байте, где закончился текущий. Размер тела запроса в байтах можно узнать из заголовка Content-Length, а если его нет, то можете считать, что его значение 0.

Что следует почитать для Вашей задумки:
1. Спеку http
2. Исходники hyper
3. Исходники actix-web

Не копируется, потому-что внутри массива maze у Вас лежат ссылки на подмассивы, и Вы копируете лишь их, а не сами массивы.
Придется скопировать на уровень глубже:const mazeCopy = maze.map(sub => sub.slice())

Хорошей практикой является не тащить зависимости в бандл.
В webpack есть externals
В rollup есть external
Если Вы вшиваете свои зависимости в бандл своего пакета - Вы без вариантов создаете дублирование кода в бандле, если мне нужны те же зависимости, что и Вашему пакету и дополнительно Ваш пакет

JS отработает раньше запросов, можете не париться
Лучше задумайтесь, а что будет, если у меня не работает Ваш JS?
Ну еще советую почитать про fetch апи, а так же, что по мимо click есть другие события

что-то мне кажется что надо слеши экранировать пробовал так /\ ничего не выходит

Да, обратный слэш нужно экранировать, так как он сам является экранирующим символом, прямой же слэш не экранирует, поэтому ничего не выходит
Пример:
\\ -> \
\\\\ -> \\

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

path.normalize( '//192.168.1.5/C$/data/data.json' )

Prop.__proto__.move поменять на Prop.prototype.move
Prop.__proto__.check_collision поменять на Prop.prototype.check_collision

Получше изучите прототипы, и чем prototype отличается от __proto__
Ну и обратите внимание на es6 class, позволяющий работать с прототипами максимально просто и правильно

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

В случаеconst cnt = document.querySelector('.container')тип можно вывести однозначно - это тип Element, а все потому, что TS знает, что значение в const точно не изменится и просто берет возвращаемый тип для document.querySelector и выводит подсказки для него.

В случае же с this.$element значение может поменяться, в том числе где-то из вне, и JS вполне позволяет изменить его на что угодно, поэтому выводится тип any, для которого подсказок нет.

Я не буду Вас агитировать перейти на TypeScript, как и расписывать, насколько он экономит время при разработке чего-либо сложнее 10-20 строчек кода. Я просто подскажу, что TS в VSCode можно врубить и для обычных JS файлов, даже не имея tsconfig.json, достаточно просто добавить комментарий // @ts-checkв начало файла, и Вы получите сразу и больше подсказок, и некоторый контроль типов. Так же добавлю, что в js файлах можно аннотировать типы через jsdoc:

// @ts-check
export class Page {
    constructor(selector, options) {
        /** @type Element */    
        this.$element = document.querySelector(selector)
        this.$element // тут работают подсказки после точки для типа Element
    }
}