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

Такие задачи однозначно решаются обходом AST. Возьмите общеизвестный парсер и инструмент для обхода его дерева, например связка из @babel/parser и @babel/traverse подойдет.
Так же можно посмотреть в какие ноды что парсится с помощью https://astexplorer.net/ - в нем несколько языков, а для js/ts на выбор есть несколько парсеров.
Вам по сути нужно найти FunctionDeclaration содержащий в body ReturnStatement и извлечь из него Identifier соответствующий имени. А для второй части - FunctionDeclaration с ArgumentsList не нулевой длины.
Ну и так как в условии сказано, что внутрь не заходить, то можно пройтись лишь по верхнему уровню, тогда @babel/traverse и не нужен даже

Выбирайте, что больше нравится:

/^(\d|\.)*$/
/^[.0-9]*$/
/^[\d.]*$/

Но я бы все же ограничил одной точкой:/^\d*\.?\d*$/

Если свойства заранее известны, то проще get/set сделать.
А Proxy перехватывает все поля без исключения. Можно разве не все хандлеры определять, вместо пропущенных будут использоваться одноименный функции из Reflect, что по сути приведет к поведению как у оригинального объекта.
Ну и да, на один объект можно повесить любое число Proxy и о них не узнает ни оригинальный объект ни другие прокси.

лишь ошибки типизации которые не мешают компиляции

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

Как проверять все файлы проекта на правильность типизации?

Скомпилировать проект.

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

И это хорошо. Если TypeScript LSP будет перепроверять весь проект на каждый чих, а не только открытые файлы, то писать что-то сложнее todo листа будет невозможно...

Знаю, существуют ESLint, TSLint.

Они тоже для статического анализа, но для немного другого. В VSCode они так же чекают только открытые файлы, из тех же соображений производительности.
TSLint устарел. ESLint ставьте отсюда: https://marketplace.visualstudio.com/items?itemNam...

Как бы это странно не звучало, но одно из главных преимуществ TypeScript - это ускорение разработки в несколько раз. Да, когда еще ничего нет - разработка незначительно замедлится, так как помимо логики нужно описать еще и типы. Но это только в начале. И это не только возможность писать большую часть кода с помощью автодополнения. Поддержка существующего кода занимает в десятки раз больше времени, чем его начальное написание. Стоит ли вложить несколько лишних часов на старте, чтоб сэкономить в последствии месяцы? Как по мне стоит.

Еще одним огромным плюсом является возможность проектировать на типах. Познав дзен TypeScript'а я перестал пользоваться UML, так как типы дают мне ту же наглядность, но при этом еще и сокращают время, так как типы - это уже код. Ну и источник правды остается один. Бизнес требования выраженные в типах не дают отклонится от них при написании логики, исключая возможность неправильной трактовки задачи. Перенеся задачу в типы, я могу обсудить ее с коллегами и исправить неточности еще до написания кода, что опять же сильно экономит время.

Ну и отвчечу на некоторые Ваши сомнения:

TSLint в VSCode прям жутко тугой

TSLint официально deprecated, вместо него стоит использовать плагин к eslint, заодно можете мой конфиг попробовать.

Типы? Есть JSDOC

JSDoc в плане типов не умеет и 10% того, что умеет TypeScript. Кроме того, никто в здравом уме не пишет JSDoc на приватную логику, а значит проверки типов там не будет. JSDoc не гарантирует корректность рефакторинга, а вот благодаря TypeScript я, опять таки, точно не забуду обновить JSDoc.

многие библиотеки nodejs не имеют типов

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

Поддержка браузерами скомпилированного кода? Да какбы почти весь JS имеет поддержку 95%+, тот же Babel уже забыл когда использовал.

Вообще это не основная задача компилятора TypeScript, а опциональная возможность. И babel + preset-env с ней справляются гораздо лучше. И никто не мешает использовать их вместе. А еще думаю вопрос времени, когда кто-то напишет оптимизатор кода использующий информацию о типах из TS.

Примерно в каждой второй есть инстансы, на которые смотришь - и чешешь репу - а как называется тип этой переменной в @types/?

import {someObject} from 'some-library';

type TypeFromValue = typeof someObject;
const valueCopy: TypeFromValue = {
    ...someObject,
    type: 'overrides',
    with: 'type check',
};

и кстати, вот пример того что JSDoc типы не умеют.

//@ts-check

и почти везде останется бесполезный any.

P.S. удачи такие типы на JSDoc описывать
P.P.S. Еще прелести современного TypeScript невозможные у...

locations[`coord_${count}`]
это же базовый синтаксис языка...

Если Вы не пишите внешнее или публичное API, то GraphQL и REST - будут крайне отвратительным выбором. Они ограничивают Вас в низкоуровневом CRUD, создавая больше проблем, чем решают, а главное затрудняют выражать Ваше API в терминах доменной области.
Посмотрите в сторону RPC протоколов, и посмотрите как элегантно на них можно описать конкретно Ваш домен. Да и выбор тут огромен: Apache Thrift, gRPC, JSON-RPC, а так же мой любимый, но почему-то малоизвестный в русскоязычном интернете E/A/?T (расшифровывается как entity/action/optional-target)

https://webpack.js.org/plugins/split-chunks-plugin/

console.log(getRandomVariant([
    {chance: 0.4, value: 'Текст1'},
    {chance: 0.2, value: 'Текст2'},
    {chance: 0.15, value: 'Текст3'},
    {chance: 0.25, value: 'Текст4'},
]));

function getRandomVariant(variants) {
    const sortedVariants = getRandomVariant.cache.get(variants) ?? getRandomVariant.cache
          .set(variants, variants.slice().sort((a, b) => b.chance - a.chance))
          .get(variants);
    let rand = Math.random();
    for (const {chance, value} of sortedVariants) {
        if (chance > rand) return value;
        rand -= chance;
    }
}
getRandomVariant.cache = new WeakMap();

правильно ли я понимаю, что при установлении например ширины 50% у дочернего, это будет зависеть от ширины родителя?

правильно, проценты считаются от родителя

если у родителя установлено 50% , то грубо говоря у дочернего получится 25% от всей "страницы"?

если родителем родителя будет body, то да

если например у родителя 80px то у дочернего будет от этих 80 отниматься?

да

и с vw/hw не понятно

vw и vh - это проценты от ширины вьюпорта и от высоты вьюпорта соответственно, расшифровывается как ViewportWidth и ViewportHeight

Первое, что на ум приходит - GROUP BY, но с ним придется как-то агрегировать остальные поля.
Еще как вариант - делать запрос на запрос с лимитом, что-то вроде:

SELECT 
       c.id AS id, 
       c.name AS name, 
       phone.phone AS phone, 
       email.email AS email 
FROM (SELECT id, name, phone, email FROM contacts LIMIT 6) AS c 
LEFT JOIN phone 
       ON c.phone = phone.phone_id 
LEFT JOIN email 
       ON c.email = email.email_id

Во-первых, современный wsl поднимает vlan и поэтому localhost (127.0.0.1) будет доступен только из Ubuntu, но не из другой системы wsl и не из винды.
Узнать текущий IP адрес можно многими способами, в том числе:
hostname -I
или
ip addr

Во-вторых, какое отношение имеет ssh к веб серверу? Открывайте в браузере.

По итогу:
- приложение должно слушать не 127.0.0.1 а ip адрес vlan, проще всего слушать все адреса через 0.0.0.0
- открывать нужно в браузере по ip адресу wsl

Можно вот такой скрипт на powershell подготовить:

$wslIP = wsl -- hostname -I
$wslIP = $wslIP.Split(" ")[0]
OpenWith "http://${wslIP}:5000/"