Restructuring Packages & Directories

[danielbate]

We currently have 26 packages in the packages directory. This is an unnecessary level of abstraction that increases build, watch, install and test times. We should look to restructure packages into a smaller logical structure. Further to this, some that were acting as a bridge between packages may be deprecated when relocated if this now makes logical sense (i.e. @fuel-ts/testcases). This issue will act as a topic for all restructuring activities, and further issues should be created per package.

Proposed Structure

[arboleya]

@danielbate Thanks for creating the issue.

Should we have individual issues per group, though?

[danielbate]

@arboleya agreed. I had added the following:

This issue will act as a topic for all restructuring activities.

But will make it more explicit around further issues.

[petertonysmith94]

Just took another quick look over this one (for my understanding of the dependencies referenced in #1356).

The consolidation of the account package has been pretty big IMO (thanks @Torres-ssf 🥇). I would say the proposed lib package would be a massive win.

Generated using pnpm-workspace-graph

[maschad]

@danielbate is there a reason why the interfaces , merkle and hasher libraries are unattached? I also wonder if math , address, crypto, hasher , merkle and transaction should be grouped together in lib, then test-utils , error. versions and interfaces should be in utils ?

[arboleya]

@maschad Thanks for your observations!

They should be attached; I probably messed up and deleted their lines.

The packages math, address, crypto, hasher, and merkle — are under lib tho.

Only transaction is not, but it could be, and we could also include a utils package.

Grouping these is always subjective. We must carefully think it through.

[maschad]

Thanks for the clarification. Based on the dependency graph @petertonysmith94 generated it seems that suggestion could work.

[petertonysmith94]

This discussion would be closed via:

• Consider merging all packages into fuels #2493

[maschad]

I think we can conclude the discussion with the issue outlined in #2493

We also arrived at consensus around this at the offsite.

[petertonysmith94]

Closing this discussion, we're moving to a single fuels package:

• Consider merging all packages into fuels #2493

(Back reference added to the issue)