You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To make it easier to make new releases with fixes and new features
To make it easier to work with Reactist locally, in development mode, alongside our product apps
To bring Reactist build process closer to how our apps are built, and support the same bundling features
🗺 Overview
Releasing new Reactist versions is cumbersome (requires manual update of changelog, manual update of new version number, generating built artifacts, etc.)
Working with Reactist locally against our product apps is difficult and error-prone. Although not stated below explicitly in any given task, hopefully an improved build process could help in this regard. For instance, right now stylesheet changes in Reactist do not reflect in our apps running locally against the local dev version of Reactist.
Reactist build process and bundling features are not 100% compatible with that of our apps. We want to support the same features (e.g. importing SVGs as React components, support the same types of stylesheet imports into JS code, etc.)
✅ Task Breakdown
Build Process
We want to unify and simplify our build process while making it faster if possible. This includes:
Support tree-shaking. Apps and other libraries using Reactist must only include strictly what they are using from it, and nothing more.
Support TypeScript, CSS modules and SVGs imported as React components. It must also support .less while we still rely on it, as we gradually move away from it.
Automated project life-cycle
Implement automation of versioning and release. This could be achieved drawing inspiration, for instance, from how jest-dom does it (powered internally by cycjimmy/semantic-release-action).
The release automation draws conclusions from the commits/PRs in the release, to determine if the release is a patch, minor or major (breaking change) release.
Push actions to main trigger a new release fully automatically, including determining the new version.
We may not be able to fit all this work within a single cycle (4-5 weeks).
The numbered list above is in order of priority. Hopefully all the checkboxes within each section are done, and no numbered section is left halfway, as they are more or less self-contained and all tasks within each are interconnected.
Post to a thread in Twist (not sure if we want that for an open source project. It could be something we achieve externally via some sort of Github-Twist integration).
🗺 Overview
✅ Task Breakdown
Build Process
We want to unify and simplify our build process while making it faster if possible. This includes:
.less
while we still rely on it, as we gradually move away from it.Automated project life-cycle
Implement automation of versioning and release. This could be achieved drawing inspiration, for instance, from how
jest-dom
does it (powered internally bycycjimmy/semantic-release-action
).This includes:
main
trigger a new release fully automatically, including determining the new version.PR review process aids
🚧 Potential problems / unknowns
We may not be able to fit all this work within a single cycle (4-5 weeks).
The numbered list above is in order of priority. Hopefully all the checkboxes within each section are done, and no numbered section is left halfway, as they are more or less self-contained and all tasks within each are interconnected.
🔮 Out of scope / future improvements
📝 Related documents & discussion
The text was updated successfully, but these errors were encountered: