Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
esbuild option #379
Comments
|
Hello! First of all I'd like to thank you for this great project! I very much agree with @pkieltyka, Preconstruct is an absolute life-saver for monorepos (thanks to everyone involved) but the build time is extremely slow for larger projects. As I can see, internally, this project uses Rollup for the build process and I think integration with something like this would not be that hard as we have tested this package in production and we had 0 issues but this can be subjective on project basis and I'd like to hear your thoughts on whether or not this is a good option. Many thanks for all your efforts. |
Could you share some numbers? I have not experienced things being slow by any means and we had some positive feedback regarding performance in the past (for example here: #364 ). Of course, using ESbuild would speed things up even more but there are some tradeoffs related to this as well, so the decision about this has to be considered from all angles. |
|
Hi! Sure, thanks for your response. So in our consultancy, we have one single codebase/monorepo which includes all our packages and our internal tools which consists of ~203 packages in total (both big and small packages combined) and the full build time for all of these packages ranges between 10-15mins (Although if you'd like I can take an accurate benchmark later) but as it was explained in #364, I totally respect the future decisions regarding this issue since this is probably such an edge-case that might not be worth investing into which either way is fine by us since this is one of those quality of life options which does not impact the project in major way. Anyway, thanks everyone for all you have done for this community. Much love. |
|
Yeah, I'm not sure esbuild would be that valuable here because because what I've found is that most large projects tend to use TypeScript these days and tsc generating declarations is the majority of the time. Though 10-15 seems extreme - are you using TypeScript and if so, how do you have it setup? One tsconfig per package or one tsconfig for the whole repo or something else? |
|
Hello! Thanks for your response!
I fully understand this decision.
That is correct, we use one tsconfig for all packages that every package extends from but do you have any suggestions for improving build performance? |
|
Try having just one tsconfig at the root rather than one per package |
hi there,
I <3 preconstruct. As the dust is settling on es modules and es6 targets (with little changes in sight, and app/tool adoption growing), and most new apps built today target these systems, it makes sense to optimize the developer experience such that it would simplify this use.
One such suggestion is to abstract the bundle/build function of preconstruct and allow a user to use either babel+rollup or esbuild. I believe this will make preconstruct perform way faster, but more importantly the esbuild will ship with the ideal default targets that most modern libs/apps expect.
The babel experience for me with preconstruct required investing in many days+hours to make decisions on what kind of target and output I'm looking to achieve (as my code does come from TS), and I preferred to skip the babel runtime, and keep it as clean es6 output, and allow front-end app bundlers transform the clean es6 to its final destination. I believe esbuild would be an ideal candidate here and elevate preconstruct greatly.
The text was updated successfully, but these errors were encountered: