Splitting up @makeswift/runtime
#450
migueloller
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Background
When a developer uses Makeswift they install @makeswift/runtime. Then, they import various things from
@makeswift/runtime/next
,@makeswift/runtime/react
, and@makeswift/runtime/next/plugin
. Many packages in our internal monorepo also depend on@makeswift/runtime
, and those import from@makeswift/runtime
directly.Also, when doing work for the runtime, it all happens inside
@makeswift/runtime
, independent of whether we're working on core modules or we're working on Next.js helpers. The only thing that's separate is the Next.js plugin, living in@makeswift/next-plugin
and re-exported at@makeswift/runtime/next/plugin
. Everything being under this big package increases the risk of us shipping modules that can't be properly code-split or tree-shaken. Also, because there's just one package, adding it as a dependency bring with it all required transitive dependencies (e.g., React, Styled Components, Apollo, etc.)Proposal
I propose we break up @makeswift/runtime into the following packages:
@makeswift/controls
- core control data definitions and types@makeswift/core
- core runtime logic, document manipulation, postMessage, etc.@makeswift/dom
- DOM runtime logic, layout measurements, etc.@makeswift/css
- CSS runtime@makeswift/react
- React runtime logic, relies on @makeswift/dom@makeswift/next
- Next.js runtime logic and helpers, relies on @makeswift/react@makeswift/components
- Builtin Makeswift componentsHow each package will depend on another and how we'll structure the layers is yet to be determined.
Technical Details
Backwards Compatibility
Alternative Approaches
Feedback
Beta Was this translation helpful? Give feedback.
All reactions