squaredev-io/matte

[RFC]: Separate Exports

Closed this issue · 3 comments

awareness481 commented

Currently, we're only shipping a single file which causes bundle sizes to be significantly inflated. I'm proposing implementing either of the two options outlined below:

Option 1: Keep current export, add single exports for each component

If we were to implement this, users would still be able to use the old exports. Ex:

import { Card } from 'matte-ui'

but they would be encouraged to use the new exports:

import { Card } from 'matte-ui/components/Card' //import path to be determined

Benefits

  1. We keep the old exports so any existing apps don't have to make changes
  2. End-user would likely not need a bundler if the export is an esm module

Drawbacks

  1. Maintaining two build outputs
  2. Bigger library size ( not to be confused with bundle size )
  3. Easy to use the old import syntax accidentally

Option 2: Remove the current export, exports components from a single file

With this proposal users would not need to change the imports but they would get the benefit of a smaller bundle size just by upgrading.

ex:

import { Card } from 'matte-ui'

Benefits

  1. Users only have to upgrade the library version
  2. Less maintenance
  3. Smaller library size

Drawback

  1. No upgrade path for users who would still like to use the old import syntax
  2. A bundler would be required
  3. Bundle-size is determined by a bundler's tree-shaking

Notes

We should provide cjs exports

cc: @ksiabani @momegas

momegas commented

@awareness481 I would like to hear your proposal 😉

  • 👍1
awareness481 commented

@momegas The 2nd option would imply having an index.ts file with an export statement for every component

// index.ts
    export * from './src/component/Nav.ts'
    export * from './src/component/Button.ts'
    // ..

In general, I find this pattern hard to work with and harder to change. I'm also worried about any potential effects it might have on tree-shaking (in most cases it should be fine).

In general, I would much prefer using the standard exports field (1st option) https://nodejs.org/api/packages.html#conditional-exports This would also make it easy to provide different exports for cjs.

As to whether we should keep the old single-file export, that should depend on whether this library is used by other projects and how hard it would be to switch to the new import syntax.

momegas commented

Great. I'm in favour. Let's discuss and plan a potential MR to solve this. Can you create the issue and we can plan / proritise it one of these days.

  • 👍1