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

С помощью нужного плагина - да. Будет и TypeScript компилироваться как надо, и разделить результат на несколько js-файлов можно автоматом. Code splitting называется.

Custom elements v1: какие советы и идеи по реализации?

Сам-то читал, учитель? Попробуй открыть свою страницу в DOM Inspector и изменить любой атрибут своего элемента. Изменения при этом не отразятся нигде.

Для того, чтобы слушать изменения в значениях атрибутов и придуман attributeChangedCallback

Custom elements v1: какие советы и идеи по реализации?

Антон Шаманов:
> а сеттеры и геттеры на что?

Это _свойства объекта_ а не _атрибуты элемента_. Последние устанавливаются только через setAttribute() или через разметку.

> а манипуляции с теневым dom разве одно и тоже что и манипуляция dom элемента?

DOM есть DOM. Не место ему в конструкторе. Если даже сейчас это работает, то при любом обновлении браузера может сломаться. Встречались мне такие поделки - в современных браузерах уже не работают.

Custom elements v1: какие советы и идеи по реализации?

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

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

Custom elements v1: какие советы и идеи по реализации?

Нельзя манипулировать деревом DOM внутри конструктора. Запрещено стандартом. Обычно эту логику помещают в connectedCallback.

Почему Worker медленнее основного потока?

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

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

Почему Worker медленнее основного потока?

Можно ещё таймеров навставлять. Прямо в код воркера. Тогда точно увидите, где тормоза.

Почему Worker медленнее основного потока?

Вы проверьте на фактические ошибки. Навставляйте coslole.log, try/catch и т.д. Убедитесь, что ваш алгоритм отрабатывает, а не должен отрабатывать

Винить технологию, вместо поиска своих ошибок - смертный грех для программиста.

Почему Worker медленнее основного потока?

Варианты:
1. Технология не работает.
2. Ваш код не работает.
Серьёзно, проверьте на ошибки свой код. В воркере другая среда исполнения. Скорее всего, ваш код просто сыпется с ошибками.

Почему при сборке вылезает ошибка "Did you forget to signal async completion"?

Поправлюсь (эдак я и сам начну понимать, что пишу :) ).

Всё-таки вызов gulp.series() возвращает функцию. Но Gulp, как и написал Андрей Галкин, не обещает, что такая функция, будучи возвращена из задания, будет вызвана. Даже если завернуть её в Promise. Так что вызывать её надо явно.

Почему при сборке вылезает ошибка "Did you forget to signal async completion"?

Непонятно, на что вы надеялись. series возвращает функцию. Так что этот код равносилен просто Promise.resolve(function() {...}). Причём функция, передаваемая в Promise, даже не вызывается.

Если уж так хочется "обещаний", то вот:

function build () {
    return new Promise(
        (resolve, reject) => gulp.series(
            clean_build, 
            gulp.parallel(
                html_build, 
                js_build, 
                css_build, 
                php_build, 
                fonts_build, 
                image_build
            )
        )(error => error === undefined ? resolve() : reject(error))
    );
}

exports.build = build;

Или то же самое через promisify:

const { promisify } = require('util');

function build () {
    return promisify(
        gulp.series(
            clean_build, 
            gulp.parallel(
                html_build, 
                js_build, 
                css_build, 
                php_build, 
                fonts_build, 
                image_build
            )
        )
    )();
}

exports.build = build;

Почему при сборке вылезает ошибка "Did you forget to signal async completion"?

Всё проще, на самом деле.

Вот реализация parallel: https://github.com/gulpjs/bach/blob/master/lib/par...
Вот реализация series: https://github.com/gulpjs/bach/blob/master/lib/ser...

Из них видно, что функции эти реализованы через callback, и не возвращают ничего. То есть return из функции build бесполезен.

Попробуйте реализовать build таким образом:

function build (done) {
    gulp.series(
        clean_build, 
        gulp.parallel(
            html_build, 
            js_build, 
            css_build, 
            php_build, 
            fonts_build, 
            image_build
        )
    )(done);
}

Почему при сборке вылезает ошибка "Did you forget to signal async completion"?

Подозреваю, что ошибка где-то в другом задании. Просто иногда "везёт", и это задание завершается вовремя.

Посмотрите сюда, например: https://github.com/gulpjs/gulp/issues/2316

Возможно, где-то в заданиях есть что-то подобное.

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

Почему нет ошибки при использовании intersection типа?

Обратиться к любому полю (a, b, c) типа type1 | type2 не получится, потому что любое из этих полей отсутствует либо в типе type1, либо в типе type2. Для решения этой проблемы используются, например, discriminator unions.

Линтинг же такой, видимо, из-за того, что не удаётся сформулировать требования строго формально. Поскольку строго формально никакой ошибки нет. А до версии 3.4 TypeScript вообще любые поля разрешал добавлять в объектный литерал в таком случае. И был формально прав!

Попробуйте так:

type type1 = {
  a: number;
  b: number;
};

type type2 = {
  c: number;
};

type type3 = type1 | type2;

const test0 = {
  c: 111,
  d: 333,                            // этого поля нет ни в type1, ни в type2,
                                        // но "лишние" поля не делают тип несовместимым
                                        // только отсутсвующие
  a: 'string, not a number!', // здесь вообще не тот тип
}
const test1: type3 = test0; // ошибки нет, ведь test0 совместим с type2

Почему тип never у пустого массива?

never[] чтобы не делать any[], очевидно. Поскольку из выражения не понятно, какой тип делать, а any - всегда плохой вариант.

Во всех случаях обработать пустой массив не получается, очевидно. Никто этого ещё не реализовал. Может и появится реализация со временем.

Как правильно тестировать функции, манипулирующие DOM-элементами?

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

Как правильно тестировать функции, манипулирующие DOM-элементами?

Этого вообще не нужно делать. Просто запускайте тесты свои. Можете в package.json добавить соответствующий пункт

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

Aetae Разумеется есть:) Называется правильная архитектура. "Правильная" - это которая без излишней сложности. Например можно ведь не работать с объектными литералами, а сделать объектную модель, соответствующую предметной области. Которая ещё и ресурсы вычислительные экономит при этом. Впрочем во фронтэнде так не принято :)

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

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

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

Aetae По-моему "больно" работать именно с разлапистыми структурами, в которых каждое поле может быть записано разными вариантами. Я же предлагаю эту вариативность использовать с умом. То есть _только_ для задания исходных значений. Но пользоваться этими значениями уже в нормализованном, более строгом виде. Это как раз излечит "боль".