-
Notifications
You must be signed in to change notification settings - Fork 676
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change to preconstruct to build #1204
Conversation
closing but hopefully gives some ideas on an alternative build to microbundle |
Thanks for the PR, @alexanderchan! I'm reopening this. Lerna is a bit of a pain right now, and migration towards Preconstruct and Changesets seems like a great idea. Contributing to Emotion is way more enjoyable than contributing to Theme UI right now. @atanasster @lachlanjc could skim over this PR and tell me what you think? |
b97cec2
to
af19f9f
Compare
@hasparus you're welcome! We've been enjoying using theme-ui and preconstruct for our builds (and not needing a watch step for dev) for our component library based on theme-ui so hopefully it works out here for you guys. Thanks for mentioning changesets, I'll definitely have to look into that too. Let me know if there's anything else I can help with. We'll probably need some help to resolve type issues from the typecheck. They appear to be valid and I'm not sure if we want to relax the types to be |
Oh, typecheck errors are actually something I don't suck at :D I'm gonna take a look. |
hey all, just FYI preconstruct v2 is out which irons out a few kinks from v1, the updates will be very minor to your PR here, but thought I'd mention it. |
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/systemui/theme-ui/cjlkp9ktq |
As mentioned by @jxnblk in #668 (comment) there were some points related to TS and microbundle. This PR is just to show the changes that could be done to adopt preconstruct.tools that used by emotion that could be considered as an alternative build system.
On my machine it drops the library build time from about 60s to 10s (cached after the initial warm build) using
yarn prepare
It has a few other benefits in addition to the speed of the build:
yarn run preconstruct dev
is run, the dev experience imho is improved in that dependent modulesdist
files link to the live version of thesrc
files so that one doesn't need to wait for a re-build. Also, direct navigation to the original src file is possible from the other packagebabel.config.js
. Sub packages don't require having any build specific configurationthe preconstruct docs do a good job of highlighting more of their why.
Note that I left the development setup as
yarn dev:init
rather than setting up"postinstall": "preconstruct dev"
but that's something to consider adding if we want to go forward with this type of change.We could also remove the
prepare
in favour of apostinstall
script since we don't technically need to build every time we install, saving us another 10s when we install.