Использование пользовательских машинописных текстов в виде NPM пакета * НЕ * в пространстве имен @types - PullRequest
0 голосов
/ 10 апреля 2020

В моей компании мы хотим автоматизировать генерацию наших наборов на основе API GraphQL и упаковать их в пакет, к которому мы можем обратиться со всеми нашими клиентами, которые используют API вместо того, чтобы полагаться на копировальную пасту. Я читал документы TypeScript и немного запутался в том, как go рассказывать TypeScript об этих пользовательских типах.

Из моих чтений TypeScript автоматически будет искать node_modules/@types/*. К сожалению, поскольку это внутренний API, и мы не хотим публиковать sh в репозитории DefiniteTyped (я не обнаружил, что вы не можете явно писать и @types/package, и это будет закрытый модуль). Таким образом, во всяком случае, это означает, что то, что мы назовем нашим пакетом, не будет автоматически проверяться TypeScript.

Я читал о types и typeRoots, думая, что это могут быть варианты, которые мне нужно использовать. Из моего прочтения types я могу указать @types, который я хочу включить в TypeScript, вариант выбора вишни. typeRoots похоже на то, что я должен использовать; однако он говорит, что только пакеты в этой опции будут включены. Мое предположение здесь заключается в том, что мне нужно будет сделать что-то вроде следующего (нам все еще нужны определения в @types):

{
  "compilerOptions": {
    "typeRoots": ["node_modules/@types", "node_modules/@companyOrg/customTypings"]
  }
}

Кто-нибудь делает аналогичную вещь и нашел способ для TypeScript включить ваши пользовательские наборы, которые не подпадают под зонтик @types? Обратите внимание, что я не говорю о создании custom.d.ts в каталоге проекта, но использую NPM пакетов, похожих на @types/react, за исключением чего-то вроде @company/our-types.

Current tsconfig.json:

{
  "compilerOptions": {
    "target": "es5",
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "allowJs": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "preserve",
    "preserveSymlinks": true,
    "typeRoots": [
      "node_modules/@types",
      "node_modules/@companyOrg/customTypings",
    ],
  },
  "include": [
    "src"
  ],
}

Также я работаю над этим локально, поэтому я использовал yarn link @company/our-types, возможно, именно в этом и заключается проблема. Я несколько раз проверил путь, и все вроде нормально.

1 Ответ

0 голосов
/ 11 апреля 2020

Позвольте мне показать пример, который работает для меня. Есть 2 пакета: типы (это может быть любое имя) и потребительские. Пакет Types содержит мои наборы в виде d.ts файлов, и у меня есть index.d.ts в root (этот файл используется в качестве точки входа по соглашению, но его можно переопределить, используя поле types в пакете. json)

// types/index.d.ts
declare namespace MyLib {
    interface MyInterface {
        id: string;
    }
}

export = MyLib;

Я делаю npm ссылку types на consumer и добавляю "types": "*" к dependencies потребителя.

{
  "name": "consumer",
  "version": "1.0.0",
  "dependencies": {
    "typescript": "^3.8.3",
    "types": "*" // <----
  }
}

Сразу после этого я могу используйте типы, экспортированные из types в consumer:

// consumer/index.ts
import { MyInterface } from "types";

const y: MyInterface = { id: "1" };

. Это работает, потому что TS ищет определений типов во всех зависимостях и позволяет использовать их без какой-либо дополнительной настройки.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...