Именованные экспорт / импорт против импорта с абсолютным путем - PullRequest
Новая
       25

Именованные экспорт / импорт против импорта с абсолютным путем

2 голосов
/ 22 апреля 2019

Я реализую библиотеку компонентов (модуль npm, и мы назовем ее awesome-components), которая состоит из кнопок, входов, выпадающих меню и т. Д., Где конечный пользователь может установить ее в своем приложении реагирования и использовать эти компоненты.Моя путаница в том, каков наилучший способ упаковать эту библиотеку для конечного пользователя?Я имею в виду два подхода:

  1. Использование файла index.js для экспорта всех компонентов, которые будут импортированы как именованные импорты.Структура папок выглядит следующим образом: 
src
  |-components
    |-Button
      |-index.jsx
    |-Input
      |-index.jsx
    |-index.js

index.js будет реализован следующим образом, 

import Button from "./Button";
import Input from "./Input";

export { Button, Input };

Пакет JSON main будет указывать на index.jsв корне компонентов.Пакет npm объединит все компоненты в один файл и будет npm pack ed и npm published ed и будет выглядеть примерно так: 

dist
  |-index.js
  |-index.js.map
  |-package.json

Конечный пользователь может импортировать эти компоненты в свое приложение какследует, 

import { Button, Input } from "awesome-components";
Не имея index.js компонентов, как указано ниже, 
src
  |-components
    |-Button
      |-index.jsx
    |-Input
      |-index.jsx

И отдельно упаковывая компоненты и отправляя их конечному пользователю, сохраняя структуру папок, которая иногда будет выглядеть следующим образом, 

dist
  |-components
    |-Button
      |-index.js
      |-index.js.map
    |-Input
      |-index.js
      |-index.js.map

Конечный пользователь может использовать эти компоненты, используя абсолютный путь следующим образом: 

import Button from "awesome-library/Button";
import Input from "awesoem-library/Input";

Меня интересует, какой метод принесет пользу конечному пользователю?Количество компонентов может вырасти до 20. Каков наилучший способ использования масштабируемости и производительности?

Большое спасибо:)

1 Ответ

2 голосов
/ 22 апреля 2019

Ваш первый подход предпочтителен по четырем основным причинам.

  • При втором подходе пути могут измениться в какой-то момент, что приведет к серьезным изменениям для всех ваших пользователей.
  • Подмодули вашего второго подхода обычно считаются частными API, на которые внешние потребители этого пакета не должны полагаться.
  • Все остальные делают это так, как вы обрисовали в своем первом подходе.
  • Несколько линтеров , таких как TSLint , жалуются при использовании импорта субмодулей из внешних пакетов.
...