-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
build: Update Lerna to v6 and use Nx caching for builds #6555
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
Conversation
size-limit report 📦
|
79c50b6
to
9c709bf
Compare
Caching can be a bit of a footgun in my experience. Wdyt about not using any cache for master/release branch CI? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good so far. Would be great to get the NX goodness + speed increase!
A couple of questions:
build:pack (formerly build:rollup) - to make this more generic, e.g. for angular
I know this is a nit but IMO pack
doesn't really describe this step well. IIUC what we're doing in this step is transpiling with rollup or "compiling" with other compilers/bundlers (ngc
in Angular for instance). I know it isn't a perfect name either but wdyt about build:transpile
?
Note that we do not need any dev commands on the top level anymore really, as with caching that shouldn't be that necessary anymore.
So the idea is to simply run build:pack
instead of build:dev
? (I guess this works, as long as build:pack
depends on build:types
)
Great change, would love to get this in!
Let's just make sure that before we merge this, we create a fake release branch and test artifact upload. I just want to make sure that we're still creating all bundles and tarballs as before.
nx.json
Outdated
"build:pack": { | ||
"dependsOn": [ | ||
"build:types", | ||
"build:pack:uncached", | ||
"^build:pack", | ||
"^build:types", | ||
"^build:pack:uncached" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Q: Why does build:pack (which iiuc is our transpiling step) depend on type checking? IIRC we purposefully ran them in parallel before, as we'd still get TS errors via build:types
.
BTW I'm not saying we should change this again, was just curious.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess ideally we can get rid of this parallel building (I'd say that nx should handle that fine) and just make use of dependent steps properly. So actually we only run build:bundle
or build:pack
and get everything we need (including the types)?
"build:bundle": { | ||
"dependsOn": [], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Q: should this also depend on ^build:types
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably, I guess! I'll add it.
yeah, good point! I guess we can disable it in those cases, should not be too hard, I'll look into it.
Yeah, I was also not super happy with Or, another alternative, make it
I guess we can also simply leave |
.github/workflows/build.yml
Outdated
# - when PR has `ci-skip-cache` label | ||
if: | ||
github.ref != 'refs/heads/master' && !startsWith(github.ref, 'refs/heads/release/') && | ||
!github.event.pull_request.labels.contains('ci-skip-cache') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea is you can add a label ci-skip-cache
to the PR, which ensures it will not do any nx caching. May be helpfup when debugging here or there (maybe we could even extend this to the other caches, like the dependency cache?)
073856d
to
f8d811d
Compare
lerna.json
Outdated
"npmClient": "yarn", | ||
"useWorkspaces": true | ||
"useWorkspaces": true, | ||
"$schema": "node_modules/lerna/schemas/lerna-schema.json" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
giga nit: can we move this line to the top of the json :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So happy about this change! Thanks for tackling this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
Hi Sentry Folks 👋 I'm James, you might possibly know me already from having created https://github.com/typescript-eslint/typescript-eslint or my work on some other popular open-source tools over the years such as ESLint, Prettier and Babel. Right now I've got my Lerna maintainer hat on 🐉 I was delighted to see this PR via Jay's tweet and that you have already pressed ahead with maximizing the benefits of Lerna's modern task-runner by enabling caching. I was the 5th employee of Nx (formerly known as Nrwl) back in 2017 and it's been so rewarding to be able build that tool as open-sourced, MIT licensed software from the very beginning. Now that it's even able to benefit other tools like Lerna, that's the cherry on top! Since our team took over stewardship of Lerna in the summer last year, I have been responsible for it, and initially that meant steadying the ship and making sure the repository got some consistent love. I'm super excited about this next phase, however, in which I can now start reaching out to other great open-source teams like yours and gather any feedback you may have and/or assist you with getting the most out of it. With that in mind, I am going to spend some time today playing with your repo to see if there are any optimizations I can suggest. Another totally optional thing - if you have a paid team Slack account, we would also be delighted to leverage Slack Connect between our workspaces to allow for frictionless ongoing communication. If that's something you are interested in, please send me a DM with your relevant Slack details: https://twitter.com/MrJamesHenry If you have a similar chat tool you would like me to join instead, then I am definitely open to that. Cheers! James |
Update Lerna to v6, which uses Nx under the hood.
Impact
For now, we only use nx for caching of build steps. We can explore, in the future, also using further nx functionality, like running only changed tasks etc.
But even now, it can cut down time of the
build
step by about 6 minutes. Overall test run times have been ~10-11 minutes for me now.Streamline package scripts
In order to setup the caching etc. reasonably, I unified the build scripts a bit. Now, there are four main scripts:
build:types
build:bundle
build:tarball
(formerlybuild:npm
) - IMHO describes better what this does, it wasn't super clear to me beforebuild:transpile
(formerlybuild:rollup
) - to make this more generic, e.g. for angularWith these, we can do a better generic task dependency graph, as we can always depend on the same types of tasks.
Note that we do not need any
dev
commands on the top level anymore really, as with caching that shouldn't be that necessary anymore.Note there is also an
build:transpile:uncached
command that can be specified by packaged for things that should never be cached. This is currently only used for utils, which generates symlinks which are not cached nicely.I got rid of the
build:extras
stuff, which is not needed anymore with this setup.Node unit tests
Node unit tests have already been split out in a previous task from browser unit test.
The challenge is that Lerna 6 requires node >=14. So for older node versions, we install lerna 3 again.
Status
There is def. some more cleanup to be made with remaining tasks etc. But we can already check it out.