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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Given that now most of our testing runs in parallel in CI, the biggest bottleneck has become the build step. Within that step, the single slowest thing we do is build integration bundles, simply because of the number of bundles which need to be created. (This is especially true now that we're creating three versions of each bundle rather than two.)
To speed things up a bit, this parallelizes the building of those bundles. Though it ends up not being as dramatic a time savings as one might hope (because the typescript plugin's caching mechanism doesn't play nicely with concurrent builds), it nonetheless drops the total build time from roughly two minutes down to 70-80 seconds in my local testing.
Side question: As far as I can see, we're currently "only" producing ES5 versions of the integration bundles. Is this because of localforage?
No, with localforage it's a cjs vs. esm question. Honestly, the reason we don't have ES6 versions is mostly because no one's ever asked for them.
(I was about to say, "Anyway, soon enough we'll only have ES6 versions," but it occurs to me that in fact if we're going to continue to publish a legacy browser bundle, we also probably are going to want to publish legacy integration and tracing bundles as well. It'll just be a matter of which JS version is the default.)
Fortunately, you need two totally separate instances of the TS plugin to target ES5 vs ES6, so those definitely can be run side by side. (Famous last words...)
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
lobsterkatie
force-pushed
the
kmclb-parallelize-integration-bundling
branch
from
Given that now most of our testing runs in parallel in CI, the biggest bottleneck has become the build step. Within that step, the single slowest thing we do is build integration bundles, simply because of the number of bundles which need to be created. (This is especially true now that we're creating three versions of each bundle rather than two.)
To speed things up a bit, this parallelizes the building of those bundles. Though it ends up not being as dramatic a time savings as one might hope (because the typescript plugin's caching mechanism doesn't play nicely with concurrent builds), it nonetheless drops the total build time from roughly two minutes down to 70-80 seconds in my local testing.
Ref: https://getsentry.atlassian.net/browse/WEB-664