feat: implement forc add and forc remove to add/remove dependencies

[JoE11-y]

Description

Close #2369

Summary:
Implements functionality for forc to add remove dependencies through cli, similar to Cargo's add and remove commands.

Work Done:

• ✅ Added forc add command to support adding both regular and contract dependencies from path, git, IPFS, or version.
• ✅ Implemented conflict checks for version + source collisions (e.g., version + git).
• ✅ Added automatic fallback to workspace-relative path for local packages.
• ✅ Introduced forc remove to cleanly remove specified dependencies from the manifest.
• ✅ Modularized update logic using DepSection enum for unified regular/contract dependency handling.
• ✅ Used toml_edit to update the manifest file while preserving formatting.

Checklist

• I have linked to any relevant issues.
• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation where relevant (API docs, the reference, and the Sway book).
  • If my change requires substantial documentation changes, I have requested support from the DevRel team
• I have added tests that prove my fix is effective or that my feature works.
• I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
• I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
• I have requested a review from the relevant team or maintainers.

[JoE11-y]

@IGI-111 this is ready for review.

I also noticed something, i was unable to trigger the lockfile update by just updating the members_manifest, it only worked when the forc.toml was already updated with new dependencies.

[codspeed-hq]

CodSpeed Performance Report

Merging #7143 will not alter performance

_{Comparing JoE11-y:feat/forc-edit-subcommands-impl (6fccaf0) with master (a70254b)}

Summary

✅ 24 untouched benchmarks

[zees-dev]

You may also want to integrate with the forc.pub registry - which would be a canonical endpoint to add dependencies.
^ Or an issue should be created to integrate with forc.pub registry - if this is to be done in a future PR.
Thoughts @sdankel, @kayagokalp?

[IGI-111]

This looks nice but you need to add some tests and fix the CI errors before we can consider merging it.

[JoE11-y]

Alright will do that.

…

On Mon, May 5, 2025, 10:47 AM IGI-111 ***@***.***> wrote: *IGI-111* left a comment (FuelLabs/sway#7143) <#7143 (comment)> This looks nice but you need to add some tests and fix the CI errors before we can consider merging it. — Reply to this email directly, view it on GitHub <#7143 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANGCG5W7LKLXHHZEX2C7FW3244XRTAVCNFSM6AAAAAB4LUHOYKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNJQGQ3TCOBXHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[JoshuaBatty]

Hey @JoE11-y thanks for the PR. Just letting you know I plan to look at this properly on Monday.

[JoE11-y]

@kayagokalp I removed the default semver fallback.

And just added the an error requesting user to specify version either via git or path or with version that way code still works in production pending when the registry lookup feature is up and running.

I also updated the tests to test for that too.

[kayagokalp]

This logic seems a little off to me, the dependencies are not members of build plan Members' refer to the workspace members (packages in a workspace, indivual packages might have dependenices attached to them which this PR aims to add/remove with a command. So we are not modifying the members, but the deps of the members). I will test in a bit but my guess is that this won't even work, until then i am blocking this PR so that it doesn't get merged accidentally. I'll update in a bit

Also there is probably no need to be this verbose and do these steps manually, we should be able to run build after modifying the manifest file, build will run build plan generation, lock updates, and all the extra logic you have here.

[JoE11-y]

First off, thank you for catching that and for all the thorough reviews so far.

I really appreciate it. I wanted to share a bit of the journey behind these changes:

• I initially pulled the target package directly from the workspace’s member_manifests() and updated it in place, expecting that to regenerate the build plan and lockfile.

• Then I discovered that updating only the in-memory manifest wasn’t enough to trigger the lockfile update. my first comment to the pr

• So with the help of and with subsequent revisions from @zees-dev , I was able to rework the pr, to focus on updating the toml file directly, performing the checks along the way.

I’ve spent countless hours on this iteration, tweaking, testing, and making sure it behaves exactly like its sibling commands. I’m confident that this approach is rock solid.

And yes that logic was from the old design.

simply shadowing it with the updatedPackageManifest will clear it up

let member_manifests = updated_package_manifest.member_manifests()?;

Thanks again for your patience and feedback. I’m excited to get this merged! ❤️

[kayagokalp]

Hey again, what i meant was that you shouldn't need to modify member_manifest at all because:

1. What you are implementing here is not related to member manifests, added dependency should not be part of member manifest.
2. It is not needed to do this manually, build plan generation handles all the steps you are doing manually, you just need to update the manifest file (forc.toml) and regenerate the build plan that will take care of everything :)

I would simply write the updated forc.toml to the disk and call build/check, or if you want to BuildPlan::from_pkg_options, this way you don't have to manage anything yourself.

If this doesn't help, give me some time, I'll prepare you a moredetaild write up

[JoE11-y]

Ohh for

1. that was the old design.

It's only being used to properly verify the package path.

As we know from cargo.

We can call the add command from either the root of a workspace or from the root of a package.

So if called from root of a workspace the package where the dependency is to be added/removed should be specified with the --package flag.

So checks to ensure that specified package is included in member_manifests are required.

Then also when you want to add another member of a workspace as a dependency to another member.

Those scenarios are where we need to access the member_manifests

That insert was part of the old design where I figured I could take out the exact manifest and then update.

2. Yeah that could work.

[kayagokalp]

I just tested the version at 6a78549 seems to be working, i am fine to keep it working and get it merged we can clean it later on :) Let's revert back to it, and I will do a refactor over your code after merging it.

[kayagokalp]

Great work on this! Thanks :) Approving this as this is getting unnecessarily long PR history, and the feature seems to be working.

My final comments are:

1. The logic to add/remove packages a little too convoluted and there are areas of improvements to seriously cut down the code size.
2. forc add without any dep to add doesn't produce any error/warning simply does nothing silently which is not great
3. The way the feature is implemented will be removing all the comments present in the Forc.toml

But given that you already put so much work on this, I think we can merge this as it is, and later on I can do a small refactor to keep this code section little bit smaller by using the existing code-paths.

[zees-dev]

Approving again; thanks for your contribution @JoE11-y!

Any additional work required should probably be captured in a TODO and/or GH issue - so it can be addressed at some point.

[JoE11-y]

I think we can handle the forc add/remove failure by adding the required field in clap for them.

#[clap(value_enum, value_name = "DEP_SPEC", required = true)]
pub dependencies: Vec<String>

Thank you @zees-dev and @kayagokalp ❤️

[JoE11-y]

@zees-dev @kayagokalp resolved the comment removal issue and the forc add without dep failure.

Thanks for helping reach this stage of the pr.
It's been an exciting one.

And my apologies for being a little over zealous.🫡

[fuel-cla-bot]

Thanks for the contribution! Before we can merge this, we need @sdankel to sign the Fuel Labs Contributor License Agreement.