Rough draft of bundling sourcemaps and original sources #253
Conversation
This will cost extra CPU time, but save on IO time and disk space, which is likely a net win for most builds. This is a first draft, which appears to work as expected (sourcemaps function correctly, vastly smaller output in BUNDLE_JAR), but doesn't yet fully reduce the number of copies we can make, and doesn't avoid copying sourcemap bundles (in cases where js bundles are not copied). There may also be caching issues, where sourcemaps are incorrect not generated or are regenerated.
|
I tested this PR, and everything works quite well. Notably, the acceleration of rebuilds is about the same as with my source maps PR, from which I can conclude that any reduction in the number of copied files noticeably speeds up the rebuild. let's merge it |
|
Excellent, that's very encouraging. The work so far prevents only the copy from each bundle jar output into the finished working dir (lots of files from lots of bundles), replaced with reading each file in one bundle when that bundle builds. We can go a bit further by avoiding yet another copy of lots of files when each one bundle builds... should also decrease memory footprint a bit more by avoiding hashing more extra files on disk. That plus hash names for sourcemaps is most of what remains here, I'll let you know when those next steps are done for another review. |
This will cost extra CPU time, but save on IO time and disk space, which is likely a net win for most builds. This is a first draft, which appears to work as expected (sourcemaps function correctly, vastly smaller output in BUNDLE_JAR), but doesn't yet fully reduce the number of copies we can make, and doesn't avoid copying sourcemap bundles (in cases where js bundles are not copied). There may also be caching issues, where sourcemaps are incorrect not generated or are regenerated.