Руслан Лопатин

Лучше вот так:

this.authService.getUuid().pipe(
  switchMap(phraseFromServer => this.authService.sendPhraseToPlugin()),
  untilDestroyed(this),
).subscribe(signedCert => {
  this.signedCert = signedCert;
})

exports.build = build();

Ну так и что вам не понятно? У вас Object испольуется там, гле ожидается Movie. Либо сделайте Resp.results типа Movie[], либо не приводите результат fetch к типу Resp

Вы неправильно поняли. Просто читайте | как "или", а & - как "и".

number | string значит, что переменная содержит либо число, либо строку.

number &string значит, что переменая будет и числом и строкой одновременно. И не важно, как это реализовано, и реализуемо ли в принципе (нет).

Вот соответствующий баг. А вот объяснение почему это не баг.

В общем случае пустой массив имеет тип never[]. Но в простом случае TypeScript умеет выводить тип изначально пустого массива по последующим операциям над ним. Типа push.

Так что реально тип test1 из вашего примера станет string[], как только будет "зафиксирован". Например, возвращён из функции или назначен в другую переменную.

Так что следующий код будет работать:

function buildArray() {
  const test1 = []; // тут будет any[]
  test1.push('str');
  test1.push(1);
}
const array = buildArray(); // тип (string | number)[]

А вот такой - уже нет

const test1 = []; // тут будет any[]
test1.push('');
const test2 = test1;
test2.push(2); // Argument of type '2' is not assignable to parameter of type 'string'.

Не нужно лишние зависимости типа core-js запихивать в конечный файл. Там должен быть только код библиотеки. Зависимости потребитель вашего пакета добавит и так. Просто добавьте их в peerDependencies.

У rollup есть опция external для этого.

Чтобы вспомогательные функции не добавлялись в конечный файл, в tsconfig нужно добавить опции "importHelpers": true, "noEmitHelpers": true, а в зависимости пакета - добавить tslib.

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

Согласно официальной документации package-lock.json предназначен быть в репозитории, чтобы все разработчики проекта работали с одним и тем же набором зависимостей.

Относительно того, что его не нужно включать в код библиотек - неправда:

• Во-первых, когда выполняется npm publish, package-lock.json автоматически исключается из опубликованного пакета (проверьте командой npm archive, например)
  
• А во-вторых, package-lock.json используется только в корне проекта. В зависимостях он игнорируется. То есть в директории node_modules/your-dependency он может присутствовать невозбранно.
  

Ответ на ваш вопрос: никогда не добавляйте package-lock.json в .gitignore