Использование машинописного текста для создания модуля узла и его импорта в качестве зависимости: повторяющийся идентификатор (TS2300)

Я создал проект (названный data_model) с некоторыми классами, полезными в других моих проектах. Я создал полный gulpfile.js, который не только компилирует мои .ts в .js, но и создает единый файл .d.ts, который экспортирует мои символы, файл называется data_model.d.ts и будет в корне проекта.

Теперь я создаю второй проект, назовем его my_cool_api, который определяет в своих зависимостях зависимость от git data_model
Запуск npm install, файлы .js загружаются в мой node_modules

Все красиво и красочно. Но папка typings.

my_cool_api

 |—— package.json
 |—— …
 |—— app.ts 
 |—— node_modules
    |—— data_model
        |—— data_model.d.ts
        |—— index.js 
        |—— lib
            |—— my_class.js 
 |—— typings
    |—— tsd.d.ts
        |—— node
        |—— …

Проблема здесь заключается в файле data_model.d.ts, потому что самые первые строки этого файла будут ссылаться на несуществующую папку типизации. Давайте взглянем

///<reference path=“typings/mongoose/mongoose.d.ts" />

declare module 'data_model' {
  import mongoose = require('mongoose');

  export class MyClass {
   …
  }
}

Это заголовок файла .d.ts, который я сейчас создаю. Я пытался продублировать папку с типизированными данными (сделать так, чтобы ее нельзя было игнорировать, поскольку .npmignore установил бы ее во время установки npm), что создает следующее

 |—— package.json
 |—— …
 |—— app.ts 
 |—— node_modules
    |—— data_model
        |—— data_model.d.ts
        |—— typings <<<<<<<<<<<<<<<<<<< ADDED
            |—— tsd.d.ts
              |—— node
              |—— ...
        |—— index.js 
        |—— lib
            |—— my_class.js 
 |—— typings
    |—— tsd.d.ts
        |—— node
        |—— …

НО это даст мне сотню «дублирующих ошибок» (я думаю, потому что вокруг будет несколько файлов node.d.ts). Например:

[16:44:33] [tsc] > /my_cool_api/typings/node/node.d.ts(1553,9): error TS2300: Duplicate identifier 'cleartext'.

Мое решение прямо сейчас — скопировать любой файл .d.ts, который я нашел в node_modules, в папку с моими типизациями и изменить первые строки (ссылки) скопированных файлов в мою относительную папку с типизациями.

ДОЛЖЕН БЫТЬ СПОСОБ ЭТОГО СДЕЛАТЬ. (Я тоже пробовал с помощью команды tsd link)
Буду очень признателен за любую помощь.


node.js typescript node-modules tsd
person Manu    schedule 03.09.2015    source источник
comment
Вчера я установил последнюю ночную сборку для Typescript 1.6, в ней есть хорошее решение для обмена кодом в пакетах npm. Я разговариваю по телефону, так что больше ничем не могу помочь, проверьте нижнюю часть этой проблемы... Надеюсь, это поможет: github.com/Microsoft/TypeScript/issues/247   -  person Sunil D.    schedule 03.09.2015
comment
Этот вопрос требует исчерпывающего ответа. Скажем, разработчик создает библиотеку машинописных текстов X с зависимостью A. Другой разработчик хочет использовать библиотеку X, но также хочет использовать зависимость A. Какое решение спустя 5 месяцев? конечно, github.com/Microsoft/TypeScript/wiki/Typings-for- npm-packages показывает нам, как разрешить X быть разрешенным, но использование A снаружи приведет к жалобе машинописного текста, говорящего, что это повторяющийся идентификатор. Есть ли репозиторий на гитхабе с подобным примером?   -  person David    schedule 01.03.2016

Ответы (2)


arrow_upward
2
arrow_downward

Проблема здесь в файле data_model.d.ts, потому что самые первые строки этого файла будут ссылаться на несуществующую папку типизации.

Не делайте этого, избегайте ссылок вообще, но особенно для сторонних типизаций. Просто передайте tsd.d.ts напрямую компилятору TypeScript (или укажите его в tsconfig.json, если он у вас есть). Вам придется переустановить наборы, используемые в вашем data_model, в ваших типизациях app (по крайней мере, те, которые видны снаружи). Да, это отстой, но на горизонте есть надежда в виде Typings.

person Vadim Macagon    schedule 27.01.2016
comment
Итак, если вы используете что-то вроде браузера, нам нужно передать ему каждый tsd.d.ts, используемый в каждой зависимости машинописного текста? - person David; 01.03.2016

arrow_upward
1
arrow_downward

Я хочу поделиться решением, которое я сейчас использую для решения этой проблемы. Это возможно, поскольку v0.10.8 из Visual Studio Code будет искать любой *.d.ts файл в вашем проекте, а не только typings папку как было раньше - и "составь" глобальную кучу определений типов.

Допустим, у нас есть эти проекты:

  1. my-module (наш собственный модуль, который мы хотим включить в качестве зависимости)
  2. my-project (наш проект)
  3. another-project
  4. ...

my-module определяет файл декларации my-module.d.ts. Не игнорируйте его в .npmignore, поэтому, как только мы импортируем его как зависимость, npm установит не только исходный код, но и файл определения.

Структура my-project будет следующей:

 |-- package.json
 |-- src
    |-- ...  
 |-- node_modules
    |-- my-module
       |-- my-module.d.ts
       |-- lib
          |-- ..
 |-- typigns
     |-- node.d.ts
     |-- ...

Код Visual Studio восстановит не только node.d.ts (и любой файл в папке typigns), но и my-module.d.ts.
Обратите внимание, что мы действительно игнорируем (добавляя его в my-module/.npmignore) папку typigns нашего модуля, почему ? Потому что, вероятно, это сгенерирует несколько файлов node.d.ts, express.d.ts и т. д.: один из модуля, а другой из проекта.

В этот момент я понял, что использовал пару (~ 20) файлов определений .d.ts среди всех своих проектов, поэтому я решил следующее:

Во-первых, я группирую каждый *.d.ts файл (кроме файлов из моих модулей) в одну папку, например ~/workspace/typings-set. Повторяющихся элементов не будет: только один файл определения node.d.ts, express.d.ts и т. д.
Затем все мои машинописные проекты создают символическую ссылку на эту папку.

$> ln -s ~/workspace/typings-set/typings typings

(Я называю это typigns по соглашению)

Теперь my-module и my-project имеют такую ​​структуру

 my-module
 |-- package.json
 |-- src
    |-- ...  
 |-- node_modules
    |-- ...
 |-- typigns =====> ~/workspace/typings-set/typings

 my-project
 |-- package.json
 |-- src
    |-- ...  
 |-- node_modules
    |-- my-module
       |-- my-module.d.ts
       |-- lib
          |-- ..
 |-- typigns =====> ~/workspace/typings-set/typings

 typings-set
  |-- README.md
  |-- tsd.json
  |-- typigns
     |-- node.d.ts
     |-- express.d.ts
     |-- socket.io.d.ts
     |-- ...
person Manu    schedule 02.03.2016
comment
Не очень удачное решение, а если: Project Y => [email protected] и Project Z => Project [email protected], [email protected]? - person David; 03.03.2016
comment
Согласен с вами на теоретическом уровне. На практике не согласен, потому что заголовочный файл (я имею в виду .d.ts) не сильно меняется между 1.1 и 1.2. Проблема между двумя основными версиями, но, опять же, вы используете ~ 20 модулей, и я рассматриваю это как предупреждение. Вы действительно заинтересованы в использовании иногда mongoose@2, а иногда mongoose@3 В любом случае, я знаю, что это не окончательное решение... просто временное путь - person Manu; 04.03.2016