2

I am implementing a component library (an npm module and we'll call it awesome-components) which consists of buttons, inputs, dropdowns etc. where an end user can install it in thier react app and use these components. My confusion is what is the best way to package this library for the end user? I have two approaches in mind,

  1. Using an index.js file to export all the components to be imported as named imports. The folder structure is as follows,
src
  |-components
    |-Button
      |-index.jsx
    |-Input
      |-index.jsx
    |-index.js

index.js will be implemented as follows,

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

export { Button, Input };

The package json's main will point to the index.js in the components root. The npm pack will bundle all the compoenents to one file and will be npm packed and npm publisheded and will look somewhat like this,

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

The end user can import these components in thier app as follows,

import { Button, Input } from "awesome-components";
  1. By not having an index.js in components as follows,
src
  |-components
    |-Button
      |-index.jsx
    |-Input
      |-index.jsx

And bundling the components seperately and ship to the end user preserving the folder structure which will somehwat look like this,

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

The end user can use these componenets using absolute path as follows,

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

My concern is, which method will benifit the end user ? The number of components can even grow upto 20. What would be the best method to use interms of scalability and performance?

Thanks alot :)

Hasitha Shan
  • 2,900
  • 6
  • 42
  • 83

1 Answers1

2

Your first approach is preferable, for four primary reasons.

  • In your second approach, the paths may change at some point, which would result in a breaking change for all your users.
  • Submodules from your second approach are usually considered private APIs that external consumers of this package should not rely upon.
  • Everyone else does it the way you outline it in your first approach.
  • Several linters, like TSLint, complain when you use submodule imports from external packages.
cengels
  • 150
  • 2
  • 6