|
Our current stripes-core setup bundles a lot of parts together:
- stripes-cli
- webpack
- stripes-config (okapi getModule)
- permissions, contexts, providers used by ui modules
- testing context
This is currently causing some limitations. The most recent issues are:
We should consider splitting it up. After working on
FOLIO-2673
Closed
for a bit this structure came to my mind:
Static - possible to package in vendor DLL:
- 3rd party libs (react, redux, etc)
- stripes vendor (all stripes-* modules) this includes stripes-core (permissions, stripesConnect, AppIcon, IntlConsumer, providers, webpack and basically all imports from stripes-core used currently from various ui-modules).
Dynamic - build based on a given stripes.config.js:
- stripes-config (includes okapi config, branding, etc) (possible to build into a separate webpack entry so it can be swapped without full rebuild
STCOR-488
Closed
)
- stripes-modules (entry points for ui modules, currently available via stripes-config getModule)
- stripes-web a tiny umbrella app which consumes stripes-core, stripes-config and stripes-modules
Definition of done
- Eliminates circular dependencies (mitigates the issues we had with reactv17)
- Easier to update/rebuild OKAPI config file
- Support improved stripes pre-compile bundle (goal is to make it 10X faster than now)
- Improved cached mechanism with the use of webpack 5
|