search

paranext / paranext-core

Electron client, extension host, and C# library for Paranext
https://paranext.github.io/paranext-core/
MIT License
17 stars 2 forks source link

Implement subpath pattern exporting for papi-components #240

Open rolfheij-sil opened 1 year ago

rolfheij-sil commented 1 year ago

Our custom components, located in lib/papi-components/src are exported from a single index.ts file. A cleaner solution would be to create a separate export file for each component.

More info can be found in the Node JS docs

Additional reads: https://github.com/audi2014/react-async-concurrent/blob/main/docs/subpath-imports.md https://github.com/vitejs/vite/discussions/8575 https://davidwells.io/blog/publishing-flat-npm-packages-for-easier-import-paths-smaller-consumer-bundle-sizes https://stackoverflow.com/questions/44345257/import-from-subfolder-of-npm-package/61829317#61829317

irahopkinson commented 1 year ago

Thanks for adding this @rolfheij-sil. I did look into this when working on #179 but it wasn't clear to me that flat paths actually effect bundle size, in fact some people say it doesn't help at all and is separate from bundling. In the end I left it out because we are using tree-shaking and I know (from testing) that does remove any unused parts of papi-components. Even for lodash (which was given as an example of flat paths in one of the linked articles) warns that it might help but it might not, e.g. if you import lodash/<A> and lodash/<B> that have a common dependent function then you will get 2 copies of that dependent function, whereas if you just import A and B from lodash directly and tree-shake then the total bundle size will be smaller because it will only have one copy of the dependent function. So I would recommend tree-shaking for extension developers at the moment. Having said that this might still be useful to do as it is the modern way of importing sub-components of a package, and esp if we can show it does make a difference to bundle size.

tjcouch-sil commented 1 year ago

I recommended this as it would make it a lot easier to understand what types and such come with which component. However, if there are disadvantages as you mention, maybe we should leave it alone. Can we do some kind of namespacing with another method to avoid throwing tons of disparate types all in one module? Thanks for the thoughts!

tjcouch-sil commented 1 year ago

Maybe we should consider subpaths for scripture utilties and hooks (assuming we end up putting hooks in here as I have been thinking maybe we should do) to keep things organized. Like here https://reviewable.io/reviews/paranext/paranext-core/468#-NfRW7MxE475_NAOStBG it's all at the same level, but that seems really hard to keep track of what's what.