Создание распространяемых потоковых пакетов с сторонними зависимостями типов

Question

У меня есть библиотека, которая использует типы потока. Он также имеет зависимость, и часть его интерфейса включает определения типов из файла flow-typed для этой библиотеки. Я использую flow-copy-source, чтобы убедиться, что в установленном пакете есть .js.flow файлы.

У меня проблема в том, что когда потребитель этой библиотеки импортирует мой модуль, импорт типов из зависимости также импортируется, но теперь потребитель должен установить собственную копию определений flow-typed для этой зависимости , Обычно это было бы хорошо, но если этот потребляющий код имеет другую версию самой этой зависимости, нет способа избежать противоречивых определений.

Конкретно, моя библиотека является оболочкой службы HTTP, использующей axios@0.18.x, и имеет такой импорт:

import type { Axios, AxiosXHRConfig } from 'axios';

AxiosXHRConfig в версии 0.18.x определения flow-typed принимает два типа параметров. Тем временем приложение , потребляющее , использует более старую версию axios и имеет другую версию определения библиотеки axios для этой более старой версии. Поскольку оба определения библиотеки имеют:

declare module "axios" {
  // ...
}

... что import type { ... } from 'axios' в библиотеке не имеет способа разрешить значение flow-typed/npm/axios_v0.18.x.js в библиотеке вместо flow-typed/npm/axios_v0.17.x.js.

приложения-потребителя.

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

Answer 1

Я использую этот подход как обходной мануал, пока не услышу о более автоматическом способе сделать это:

1. Создать /src/interface.js файл потока только с открытым интерфейсом для моей библиотеки
2. Пусть мой клиентский класс реализует этот открытый интерфейс
3. Прекратите использование flow-copy-source
4. Публикуйте как мой /src, так и переносимый каталог /lib.
5. Добавитьindex.js и index.js.flow, которые стирают набор для реализации интерфейса, например:

index.js:

module.exports = require('./lib/client').default;

index.js.flow:

// @flow

import type { FooClient as _FooClient } from './src/interface';
export type FooClient = _FooClient;

const Client: Class<FooClient> = require('./lib/client').default;

export default Client;

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