When @ethersproject will be updated ?

[anarkrypto]

Hello!

I saw in @ethersproject's individual packages a possible solution to reduce the size of my bundles.

But I noticed that the project is not as up to date as the umbrella package.

[KagamiChan]

Looks like the source code is no longer a mono-repo form so it appears that there won't be any individual packages any more for v6

I did not find a roadmap or announcement thing so I don't know why the decision is made, but I would think v5's structure is better: my project does not use any cryptography algorithm in JS and mainly using ethers' orther parts (bytes, conversions, big number), so ethers v5 helps me find out that I did not include any of them by mistake

[ricmoo]

The “roadmap” is usually just random polls on my Twitter account and on the branches on this repo, but if you are just using smaller isolated utilities within ethers, you still shouldn’t see anything crypto related pulled into your project. Tree-shaking by file works very well, and v6 makes sure to keep anything like that separated by file-boundaries so dependants don’t pull in anything they don’t need.

I’ve added a longer-form response below too. ;)

[KagamiChan]

Thanks for your response, I get your point. Tree shaking should be useful to elminate code that are not in use, and save the bundle size.

But the problem could be from project management: when I need to avoid any crypto related JS code for v6, I need to make sure all the relevent methods are avoided, this would be difficult than v5 because it could be directed controlled by looking into the lockfile for crypto dependencies. And sometimes it's not easy to tell if or not a method depends on any crypto related code, the call stack could be long, and there might be some if-else branches and runtime detections

anyway I think my requirement is the very minority, so I'm OK with the new structure

[anarkrypto]

I use a monorepo, but none of my packages need more than 2 or 3 ethers.js packages. However, all of them can be installed separately and it doesn't make sense for my case have to install ethers.js umbrella on all of them.

@ricmoo I would very much appreciate you to give a position on this issue.

Is the current architecture change permanent?
Are there expectations of going back to monorepo?
I am curious about the reason for the current decision to move it.

[ricmoo]

The change to tree-shaking is definitely permanent. It greatly reduces the complexity for development and the build process is much simpler. With tree-shaking, there should also be no increase in package size (and in most cases, the size will decrease, since the boiler plate introduced by packages is removed). I’ve added a longer form response below too. ;)

[ricmoo]

There is little need with modern tools to break the package apart into myriad packages as was done in v5, since with proper organization of files (which v6 does), tree-shaking performs much better than monorepos at producing smaller code footprints.

A monorepo requires a lot more package management overhead (which slows down development and turn around on features and bug fixes; as I am one person, the less time I spend on administrative tasks, the more time I can spend on coding ;)) and monorepos results in larger bundles anyways. :)

The versioning with a monorepo also lead to a lot of dependency confusion and mismanagement by dependants, which often resulted in multiple versions of the same package being installed, further inflating the size of a project’s footprint.

I wrote (and spent a lot of time on) reticulate for the purpose of managing the monorepo, but after experimenting with tree-shaking and building a few projects on both versions of v6, it was obvious that the monorepo pattern is no longer necessary and has far more downsides.

Does that help explain the decision? Feel free to inquire more. :)

[anarkrypto]

Got it. Tree-shaking makes sense for your project. Thanks.