Чем создавать правильные .d.ts?

Question

[copal]

Написал проект на .ts + .tsx используя модульный нативный стиль, но мучаюсь целый день в попытках собрать из него правильные .d.ts. То что генерирует сам ts хоть и является декларацией, но повторяет структуру проекта, а хотелось бы чтобы все было в одном файле. И ещё не работает, при подключении модуля выдает кучу ошибок. Что делать?

Answer 1

[Станислав Макаров]

1. Посмотрите вот эти тулы, они называются по-разному, но такое ощущение, что делают одно и то же, как раз то, что вы хотите:

• dts-bundle-generator
  
• dts-bundle
  
• dts-builder
  
• dts-generator
  

2. Подпишитесь на этот таск: Proposal: Bundling TS module type definitions, чтобы следить за появлением решения "из коробки". Сейчас вроде как нет его.

Comments

[copal]

А Вы лично пользовались ими?

[Станислав Макаров]

copal коллеги использовали dts-bundle, правда Реакта у нас не было.

[copal]

Станислав Макаров: а Вы случаем не помните какие именно декларации собирает то чему пользовались Ваши коллеги? Они все разные и все неправильные. А правильную я как раз и ищу. То чем пользовались собирает из кода или из деклараций сгенерированного чем-то другим? В конфиге на гитхабе даже нет пункта "ссылка на код", там только ссылки на .d.ts

[Станислав Макаров]

copal почему же из кода? Эта тула вроде только готовые d.ts умеет клеить. Т.е. сначала просишь TS сгенерить их, потом этой тулой склеиваешь. У нас вроде как сейчас glob стоит на все d.ts в сборочной директории (что-то вроде output/**/*.d.ts)

[copal]

Станислав Макаров: самый последний собирает по коду, но дело в том что он собирает не так как во всех .d.ts из декларативных хранилищ. И предложенный Вами тоже странно собирает, все файлы в нем красные, то есть в чем-то нуждаются и при использовании полученной декларации сборщик вываливает тысячу ошибок.
Вы не знаете с чем это может быть связано?

[copal]

Станислав Макаров: мне кажется я понял почему все красное. Он собирает все пути как "a/b/s", а нужно "./a/b/c". Вы не знаете как указать чтобы он так делал?

[copal]

Станислав Макаров: хотя я уже сомневаюсь что это из-за этого..

[copal]

Станислав Макаров: ага, я разобрался. Эта херь генерирует нерабочее говно так как declare module не может быть вложенными. А она их именно так и делает.

[copal]

Станислав Макаров: а ещё он багнутый, говорите не может найти файлы .d.d.ts, но их же блин нет и ошибка это не моя так как я не работаю с этими файлами. Короче полное говно фиг его знает что Вы собирали им, наверное hello word.

[Станислав Макаров]

copal ох сколько коментов..

> фиг его знает что Вы собирали им, наверное hello word.
Да вроде побольше будет, чем хеллоуворлд, не знаю что у вас за проблемы такие.. Спрошу, как будет возможность, может тулу поменяли потом, или структура зависимостей у вас другая..

А собственно проясните всё-таки ситуацию. Какую модульную систему вы используете? Чем бандл собираете (иначе зачем вам мержить декларации)? Там вроде если amd или system, то TS сам вам и js-файл смержит, и d.ts тоже, могу демку сделать.

[copal]

Станислав Макаров: в общем вот какое дело.. Модули использую commonjs собираю webpack ts-loader+babel-loader при этом у ts выставлен флаг declaration. Декларации он собирает не в один файл, а в точности повторяет структуру проекта + начало дерева происходит не с текущей директории, а от самого корня файловой системы.

Дальше я собираю с помощью dts-bundle указывая в настройках

dts.bundle({
    name: "my-lib",
    main: "dist/my-lib/index.d.ts",
    referenceExternals: false,
    out: "./index.d.ts",
    baseDir: "./dist/my-lib/"
});

и на выходе из кода ниже получаю декларацию, которая ниже кода.

class A{}

import A from "./A";
class B{}

declare module "my-lib" {
    export * from "my-lib/A";
    export * from "my-lib/B";
}

declare module "my-lib/A" {
    class A{}
}

declare module "my-lib/B" {
    import A from "my-lib/A";
    class B{}
}

В принципе после двух дней дрочева я могу согласится что это приемлемый результат. Но есть одно НО которое не дает покоя - во всех декларациях которые я использую код выглядит вот так -

declare module MyLib {
    class A{}

    class B{}
}

declare module "my-lib" {
    export = MyLib;
}

Что скажите?)

[copal]

А с багом про .d.d.ts я разобрался. Дело было в том что когда компилятор ts создавал декларации начиная с самого корня файловой системы, то я удалял лишнее и папку src переименовывал в my-lib. При этом ide считала что пути меняются и почему-то импорты вида "my-lib/A" изменяла на "my-lib/A.d". Естественно я такого не ожидал и счел что это dts-bundle делает.

[Станислав Макаров]

copal
> во всех декларациях которые я использую код выглядит вот так ...
да, действительно странно. TS так не делает.. Возможно заморочки из-за commonjs-экспортов. Вообще результат из первого куска куда более чем приемлемый, собтвенно все как и должно быть. Чтобы решить проблему с export = MyLib могу предложить такой изврат: компильте основной бандл с кодом и d.ts в два прохода с разными tsconfig.json: первый проход как сейчас, БЕЗ генерации деклараций, а второй - с генерацией деклараций и с параметром outFile. В самом файле, указанном в outFile ничего толкового не будет, а вот декларации должны сгенериться и смержиться (!) в один файл (только с расширением d.ts). Я совсем не уверен, что это корректный способ и что не вылезут неприятности, но сам TS довольно неплохо мержит d.ts , если компилить с ключом outFile.

[copal]

Станислав Макаров: спасибо Вам за уделенное мне время, я пока решил остановится и оставить создание деклараций до тех времен, когда разработчики ts договорятся по импортам с разработчиками js и все сведется к обычной компиляции, а не выварачиванию наизнанку и трату двух с четвертью дней.