Организация библиотеки Typescript - PullRequest
Новая
       5

Организация библиотеки Typescript

0 голосов
/ 17 сентября 2018

Я только что преобразовал библиотеку JavaScript в машинописный текст.Моя проблема в том, что я не знаю, как это организовать.Это библиотека, включающая компоненты, каждый из которых использует разные классы, типы, классы ошибок и т. Д. Некоторые компоненты зависят от других компонентов.

Мой первоначальный подход состоял в том, чтобы экспортировать все на корневом уровне. 

export * from "./component1";
export * from "./component2";
export * from "./component3";

Так что я могу использовать это так: 

import { MyClassFromComponent1, MyTypeFromComponent2 } from "mylib"

Это нормально для использования, ноэто все в одном месте и с IDE и автозаполнением, это немного грязно.

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

import * as _component1 from "./component1";
import * as _component2 from "./component2";
import * as _component3 from "./component3";

export const component1 = _component1;
export const component2 = _component2;
export const component3 = _component3;

И я смог использовать его так: 

import component1 from "mylib"

const { MyClass1 } = component1;

Но, таким образом, я не могу импортировать типы машинописи и не могу выполнить деструктуризацию импорта, как (конечно, она не поддерживается с именованным импортом) 

import { component1: { MyClassComponent1 } } from "mylib"

Есть ли рекомендуемый способ справиться с таким делом?А как насчет пространств имен (я должен сказать, что это все еще сбивает меня с толку).

1 Ответ

0 голосов
/ 18 сентября 2018

На сегодняшний день лучшим подходом является:

  • экспортирует простые функции, классы, константы как таковые, не заключая их в какой-либо объект или класс. Итак, ваш первый подход import { MyClassFromComponent1, MyTypeFromComponent2 } from "mylib" очень хорош (я буду обсуждать пространство имен позже). Таким образом, ваш пакет будет потрясти дерево, что означает, что такой пакет, как Webpack / Parcer, может извлечь из вашего пакета только то, что именно требуется пользователю.
  • избегать экспорта по умолчанию. Честно говоря, я забыл почему, но сейчас это соглашение.

О пространстве имен. Обычный способ - просто использовать основные функции, классы и другие экспортируемые объекты в скрипте main (который определяется полем main package.json). Любой другой материал обычно помещается в его собственную подпапку (эта подпапка находится там же, где находится сценарий main). Таким образом, импорт содержимого из вашей упаковки будет выглядеть так: 

import {importantFunc, importantComponent} from "mylib"
import {secondaryStuff} from "mylib/feature1"

Мой личный подход, хотя, если вам интересно, это поместить скрипт main и все подпапки в папку "./api", поэтому импорт будет выглядеть так: 

import {importantFunc, importantComponent} from "mylib/api"
import {secondaryStuff} from "mylib/api/feature1"

Мне нравится этот способ, потому что он дает пользователю четкое представление о том, что именно выставлено пакетом. В противном случае пользователь может быть не уверен в том, что "mylib/feature1" является импортируемым (то есть является частью API) или это просто внутренняя часть пакета.

...