{"owner":"FuelLabs","repo":"sway","hasSkills":true,"totalSkillsCount":35,"totalTokensCount":7047,"categories":["command-prompt","anthropic-skill","plugin-manifest"],"hasMcp":false,"mcpConfig":null,"found":["docs/book/src/forc/commands/forc_add.md","docs/book/src/forc/commands/forc_addr2line.md","docs/book/src/forc/commands/forc_build.md","docs/book/src/forc/commands/forc_check.md","docs/book/src/forc/commands/forc_clean.md","docs/book/src/forc/commands/forc_completions.md","docs/book/src/forc/commands/forc_contract-id.md","docs/book/src/forc/commands/forc_init.md","docs/book/src/forc/commands/forc_new.md","docs/book/src/forc/commands/forc_parse-bytecode.md","docs/book/src/forc/commands/forc_plugins.md","docs/book/src/forc/commands/forc_predicate-root.md","docs/book/src/forc/commands/forc_remove.md","docs/book/src/forc/commands/forc_template.md","docs/book/src/forc/commands/forc_test.md","docs/book/src/forc/commands/forc_update.md","docs/book/src/forc/commands/index.md","docs/book/src/forc/plugins/forc_client/forc_call.md","docs/book/src/forc/plugins/forc_client/forc_deploy.md","docs/book/src/forc/plugins/forc_client/forc_run.md","docs/book/src/forc/plugins/forc_client/forc_submit.md","docs/book/src/forc/plugins/forc_client/index.md","docs/book/src/forc/plugins/forc_crypto.md","docs/book/src/forc/plugins/forc_debug.md","docs/book/src/forc/plugins/forc_doc.md","docs/book/src/forc/plugins/forc_fmt.md","docs/book/src/forc/plugins/forc_lsp.md","docs/book/src/forc/plugins/forc_migrate.md","docs/book/src/forc/plugins/forc_node.md","docs/book/src/forc/plugins/forc_publish.md","docs/book/src/forc/plugins/index.md","forc-plugins/forc-debug/README.md","forc-plugins/forc-doc/README.md","forc-plugins/forc-doc/src/licenses/README.md","forc-plugins/forc-publish/README.md"],"skills":{"docs/book/src/forc/commands/forc_add.md":"# forc add\n\nAdds one or more dependencies to a `Forc.toml` manifest.\n\n## **Usage**\n\n```bash\nforc add [OPTIONS] ...\n```\n\n## **Arguments**\n\n* ``: List of dependencies in the format `name[@version]` (e.g., `custom_lib@0.1.0`, `custom_contract`)\n\n## **Options**\n\n* `--path `: Add a local path dependency.\n* `--git `: Add a Git-based dependency.\n\n * Can be combined with one of:\n\n * `--branch `\n * `--tag `\n * `--rev `\n* `--ipfs `: Add a dependency sourced from IPFS.\n* `--contract-dep`: Add to `[contract-dependencies]` instead of `[dependencies]`.\n* `--salt `: Salt to use for contract deployment (only applies to contract dependencies).\n* `--package `: Apply change to a specific package in a workspace.\n* `--manifest-path `: Path to the `Forc.toml`.\n* `--dry-run`: Show what would be changed without writing to the file.\n* `--offline`: Do not fetch any remote dependencies.\n* `--ipfs-node `: IPFS node to use for IPFS-sourced dependencies.\n","docs/book/src/forc/commands/forc_addr2line.md":"# forc addr2line\n","docs/book/src/forc/commands/forc_build.md":"# forc build\n","docs/book/src/forc/commands/forc_check.md":"# forc check\n","docs/book/src/forc/commands/forc_clean.md":"# forc clean\n","docs/book/src/forc/commands/forc_completions.md":"# forc completions\n","docs/book/src/forc/commands/forc_contract-id.md":"# forc contract-id\n","docs/book/src/forc/commands/forc_init.md":"# forc init\n","docs/book/src/forc/commands/forc_new.md":"# forc new\n","docs/book/src/forc/commands/forc_parse-bytecode.md":"# forc parse-bytecode\n","docs/book/src/forc/commands/forc_plugins.md":"# forc plugins\n","docs/book/src/forc/commands/forc_predicate-root.md":"# forc predicate-root\n","docs/book/src/forc/commands/forc_remove.md":"# forc remove\n\nRemoves one or more dependencies from a `Forc.toml` manifest.\n\n## **Usage**\n\n```bash\nforc remove [OPTIONS] ...\n```\n\n## **Arguments**\n\n* ``: List of dependencies to remove by name (e.g., `custom_lib`, `custom_contract`)\n\n## **Options**\n\n* `--contract-dep`: Remove from `[contract-dependencies]` instead of `[dependencies]`.\n* `--package `: Target a specific package in a workspace.\n* `--manifest-path `: Path to the `Forc.toml`.\n* `--dry-run`: Preview what would be removed without making any changes.\n* `--offline`: Prevent forc from fetching metadata or resolving versions remotely.\n* `--ipfs-node `: IPFS node to use for reference.\n","docs/book/src/forc/commands/forc_template.md":"# forc template\n","docs/book/src/forc/commands/forc_test.md":"# forc test\n","docs/book/src/forc/commands/forc_update.md":"# forc update\n","docs/book/src/forc/commands/index.md":"\nHere are a list of commands available to forc:\n","docs/book/src/forc/plugins/forc_client/forc_call.md":"# forc call\n","docs/book/src/forc/plugins/forc_client/forc_deploy.md":"# forc deploy\n","docs/book/src/forc/plugins/forc_client/forc_run.md":"# forc run\n","docs/book/src/forc/plugins/forc_client/forc_submit.md":"# forc submit\n","docs/book/src/forc/plugins/forc_client/index.md":"# forc-client\n\nThe forc plugin for interacting with a Fuel node.\n\nSince transactions are going to require some gas, you need to sign them with an account that has enough coins to pay for them.\n\nWe offer multiple ways to sign the transaction:\n\n 1. Sign the transaction via your local wallet using `forc-client` which integrates with our CLI wallet, `forc-wallet`.\n 2. Use the default signer to deploy to a local node\n 3. Use `forc-wallet` to manually sign transactions, and copy the signed transaction back to `forc-client`.\n\nThe easiest and recommended way to interact with deployed networks such as our testnets is option 1, using `forc-client` to sign your transactions which reads your default `forc-wallet` vault. For interacting with local node, we recommend using the second option, which leads `forc-client` to sign transactions with the private key that comes pre-funded in local environments.\n\n## Option 1: Sign transactions via forc-client using your local forc-wallet vault\n\nIf you've used `forc-wallet` before, you'll already have a secure, password-protected vault holding your private key written to your file-system. `forc-client` is compatible with `forc-wallet` such that it can read that vault by asking you your password and use your account to sign transactions.\n\nExample:\n\n```console\n> forc deploy\n\n Building /Users/yourname/test-projects/test-contract\n Finished release [optimized + fuel] target(s) in 11.39s\n Confirming transactions [deploy impl-contract]\n Network: https://testnet.fuel.network\n Wallet: /Users/yourname/.fuel/wallets/.wallet\n✔ Wallet password · ********\n? Wallet account ›\n❯ [0] fuel12pls73y9hnqdqthvduy2x44x48zt8s50pkerf32kq26f2afeqdwq6rj9ar - 0.002197245 ETH\n [1] fuel1vzrm6kw9s3tv85gl25lpptsxrdguyzfhq6c8rk07tr6ft5g45nwqqh0uty - 0.001963631 ETH\n? Do you agree to sign 1 transaction? (y/n) › yes\n Finished deploying impl-contract https://app.fuel.network/contract/0x94b712901f04332682d14c998a5fc5a078ed15321438f46d58d0383200cde43d\n Deployed in block https://app.fuel.network/block/5958351\n```\n\nAs it can be seen from the example, `forc-client` asks for your password to decrypt the `forc-wallet` vault, and list your accounts so that you can select the one you want to fund the transaction with.\n\n## Option 2: Using default signer\n\nIf you are not interacting with a deployed network, such as testnets, your local `fuel-core` environment can be structured such that it funds an account by default. Using `--default-signer` flag with `forc-client` binaries (run, deploy) will instruct `forc-client` to sign transactions with this pre-funded account. This makes it a useful command while working against a local node.\n\nExample:\n\n```console\n> forc deploy --default-signer\n\n Building /Users/test/test-projects/test-contract\n Finished release [optimized + fuel] target(s) in 11.40s\n Confirming transactions [deploy impl-contract]\n Network: http://127.0.0.1:4000\n Finished deploying impl-contract 0xf9fb08ef18ce226954270d6d4f67677d484b8782a5892b3d436572b405407544\n Deployed in block 00000001\n```\n\n## Option 3: Manually signing through forc-wallet (Deprecated)\n\nThis option is for creating the transaction first, signing it manually, and supplying the signed transaction back to forc-client. Since it requires multiple steps, it is more error-prone and not recommended for general use cases. Also this will be deprecated soon.\n\n1. Construct the transaction by using either `forc deploy` or `forc run`. To do so simply run `forc deploy --manual-sign` or `forc run --manual-sign` with your desired parameters. For a list of parameters please refer to the [forc-deploy](./forc_deploy.md) or [forc-run](./forc_run.md) section of the book. Once you run either command you will be asked the address of the wallet you are going to be signing with. After the address is given the transaction will be generated and you will be given a transaction ID. At this point CLI will actively wait for you to insert the signature.\n2. Take the transaction ID generated in the first step and sign it with `forc wallet sign --account tx-id `. This will generate a signature.\n3. Take the signature generated in the second step and provide it to `forc-deploy` (or `forc-run`). Once the signature is provided, the signed transaction will be submitted.\n\n## Other useful commands of `forc-wallet`\n\n- You can see a list of existing accounts with `accounts` command.\n\n```sh\nforc wallet accounts\n```\n\n- If you want to retrieve the address for an account by its index you can use `account` command.\n\n```sh\nforc wallet account \n```\n\n> If you want to sign the transaction generated by `forc-deploy` or `forc-run` with an account funded by default once you start your local node, you can pass `--default-signer` to them. Please note that this will only work against your local node.\n>\n> ```sh\n> forc-deploy --default-signer\n> ```\n>\n> ```sh\n> forc-run --default-signer\n> ```\n\nBy default `--default-signer` flag would sign your transactions with the following private-key:\n\n```sh\n0xde97d8624a438121b86a1956544bd72ed68cd69f2c99555b08b1e8c51ffd511c\n```\n\n## Selecting a target network\n\nBy default, `local` is used for the target network. To interact with the latest testnet, use the `--testnet` flag. When this flag is passed, transactions created by `forc-deploy` will be sent to the latest `testnet`:\n\n```sh\nforc-deploy --testnet\n```\n\nThe same can be done to target mainnet:\n\n```sh\nforc-deploy --mainnet\n```\n\nIt is also possible to pass the exact node URL while using `forc-deploy` or `forc-run` which can be done using `--node-url` flag:\n\n```sh\nforc-deploy --node-url https://mainnet.fuel.network\n```\n\nAnother alternative is the `--target` option, which provides useful aliases to all targets. For example if you want to deploy to `testnet` you can use:\n\n```sh\nforc-deploy --target testnet\n```\n\nSince deploying and running projects on the testnet cost gas, you will need coins to pay for them. You can get some using the [testnet faucet](https://faucet-testnet.fuel.network/).\n\n## Delayed transactions\n\nFor delayed transactions, you can use the `--submit-only` flag. This flag allows you to submit the transaction without waiting for its finalization.\n\nOne use case for this is multisig transactions, where a deployment transaction may stay in a pending state while waiting for all signatures.\n\n```sh\nforc-deploy --submit-only\n```\n\n## Deployment Artifacts\n\nforc-deploy saves the details of each deployment in the `out/deployments` folder within the project's root directory. Below is an example of a deployment artifact:\n\n```json\n{\n \"transaction_id\": \"0xec27bb7a4c8a3b8af98070666cf4e6ea22ca4b9950a0862334a1830520012f5d\",\n \"salt\": \"0x9e35d1d5ef5724f29e649a3465033f5397d3ebb973c40a1d76bb35c253f0dec7\",\n \"network_endpoint\": \"http://127.0.0.1:4000\",\n \"chain_id\": 0,\n \"contract_id\": \"0x767eeaa7af2621e637f9785552620e175d4422b17d4cf0d76335c38808608a7b\",\n \"deployment_size\": 68,\n \"deployed_block_id\": \"0x915c6f372252be6bc54bd70df6362dae9bf750ba652bf5582d9b31c7023ca6cf\"\n}\n```\n\n## Proxy Contracts\n\n`forc-deploy` supports deploying proxy contracts automatically if it is enabled in the `Forc.toml` of the contract. This feature enables upgradeable contracts by deploying a proxy that forwards calls to an implementation contract, allowing you to upgrade the implementation without changing the proxy address.\n\n### Configuration\n\nTo enable proxy deployment, add a `[proxy]` table to your `Forc.toml`:\n\n```TOML\n[project]\nname = \"test_contract\"\nauthors = [\"Fuel Labs \"]\nentry = \"main.sw\"\nlicense = \"Apache-2.0\"\nimplicit-std = false\n\n[proxy]\nenabled = true\n```\n\nThe proxy configuration supports two fields:\n\n- `enabled` (boolean, required): Whether to deploy a proxy contract\n- `address` (string, optional): Address of an existing proxy contract to update\n\n### Fresh Proxy Deployment\n\nIf there is no `address` field present under the proxy table, like the example above, `forc` will automatically create a proxy contract based on the [SRC-14](https://github.com/FuelLabs/sway-standards/blob/master/docs/src/src-14-simple-upgradeable-proxies.md) implementation from [sway-standards](https://github.com/FuelLabs/sway-standards). The deployment process:\n\n1. **Deploy Implementation Contract**: Your contract is deployed as the implementation\n2. **Generate Proxy Contract**: A standard SRC-14 proxy contract is generated\n3. **Deploy Proxy Contract**: The proxy is deployed with your implementation as the target\n4. **Initialize Proxy**: The proxy is initialized with the deploying account as the owner\n5. **Update Manifest**: The proxy address is automatically added to your `Forc.toml`\n\nAfter deployment, you'll see output similar to:\n\n```console\nDeploying contract test_contract chunks\nFinished deploying test_contract 0x440b...925\nFinished deploying proxy contract for test_contract 0x19d4...f7\nInitialized proxy contract for test_contract\n```\n\nThe `Forc.toml` will be automatically updated with the proxy address:\n\n```TOML\n[proxy]\nenabled = true\naddress = \"0x19d465200575ebd085300242002efcda38db99e22449a5c1346588efe9ced7f7\"\n```\n\n### Updating Existing Proxy\n\nIf you want to update the target of an existing [SRC-14](https://github.com/FuelLabs/sway-standards/blob/master/docs/src/src-14-simple-upgradeable-proxies.md) compliant proxy contract, specify its address in the `address` field:\n\n```TOML\n[project]\nname = \"test_contract\"\nauthors = [\"Fuel Labs \"]\nentry = \"main.sw\"\nlicense = \"Apache-2.0\"\nimplicit-std = false\n\n[proxy]\nenabled = true\naddress = \"0xd8c4b07a0d1be57b228f4c18ba7bca0c8655eb6e9d695f14080f2cf4fc7cd946\" # example proxy contract address\n```\n\nWhen an `address` is present, `forc` will:\n\n1. Deploy the new implementation contract\n2. Call the existing proxy's `set_proxy_target` method to update the target\n3. The proxy address remains the same, providing seamless upgrades\n\n### Transaction Details\n\nWhen deploying with proxy enabled, you'll see multiple transactions in the confirmation:\n\n- One transaction to deploy the implementation contract\n- One additional transaction to deploy the proxy (for fresh deployments) or update the target (for existing proxies)\n\nExample output:\n\n```console\nConfirming transactions [deploy test_contract + deploy proxy]\nNetwork: https://testnet.fuel.network\n```\n\n### Storage Slots\n\nThe proxy contract includes both its own storage slots and preserves the storage slots from your implementation contract, ensuring that contract state is properly maintained across upgrades.\n\n### Important Notes\n\n- The proxy owner (initially set to the deploying account) has exclusive rights to update the proxy target\n- Once a proxy is deployed, the address in your `Forc.toml` allows for automatic target updates on subsequent deployments\n- Proxy contracts work with both regular and [chunked contracts](#large-contracts) (contracts over 100kB)\n- The implementation uses the SRC-14 standard for maximum compatibility with the Fuel ecosystem\n\n## Large Contracts\n\nFor contracts over the maximum contract size limit (currently `100kB`) defined by the network, `forc-deploy` will split the contract into chunks and deploy the contract with multiple transactions using the Rust SDK's [loader contract](https://github.com/FuelLabs/fuels-rs/blob/master/docs/src/deploying/large_contracts.md) functionality. Chunks that have already been deployed will be reused on subsequent deployments.\n\n## Deploying Scripts and Predicates\n\n`forc deploy` now supports deploying scripts and predicates in addition to contracts. These are deployed as blobs with generated loaders for efficiency.\n\nScripts and predicates are deployed automatically when you run `forc deploy` on a project that contains them. The deployment process differs slightly from contract deployment:\n\n1. For scripts and predicates, the bytecode is uploaded as a blob.\n2. A loader is generated that can load and execute the blob.\n3. The loader bytecode is saved in the project's output directory.\n\nAfter deployment, you'll find new files in your project's output directory:\n\n- For scripts: `-loader.bin`\n- For predicates: `-loader.bin` and `-loader-root`\n\nThe loader files contain the bytecode necessary to load and execute your script or predicate from the deployed blob.\n\nThis new deployment method allows for more efficient storage and execution of scripts and predicates on the Fuel network.\n\nNote: Contracts are still deployed directly, not as blobs given that the contract size is under the maximum contract size limit defined by network (currently `100kB`).\n","docs/book/src/forc/plugins/forc_crypto.md":"# forc crypto\n","docs/book/src/forc/plugins/forc_debug.md":"# forc debug\n","docs/book/src/forc/plugins/forc_doc.md":"# forc doc\n","docs/book/src/forc/plugins/forc_fmt.md":"# forc fmt\n","docs/book/src/forc/plugins/forc_lsp.md":"# forc lsp\n","docs/book/src/forc/plugins/forc_migrate.md":"# forc migrate\n","docs/book/src/forc/plugins/forc_node.md":"# forc node\n","docs/book/src/forc/plugins/forc_publish.md":"# forc publish\n","docs/book/src/forc/plugins/index.md":"# Plugins\n\nPlugins can be used to extend `forc` with new commands that go beyond the native commands mentioned in the previous chapter. While the Fuel ecosystem provides a few commonly useful plugins (`forc-fmt`, `forc-client`, `forc-lsp`, `forc-migrate`), anyone can write their own!\n\nLet's install a plugin, `forc-install`, and see what's underneath the plugin:\n\n```sh\ngit clone https://github.com/darthbenro008/forc-install\ncd forc-install\ncargo install --path .\n```\n\nCheck that we have installed `forc-install`:\n\n```console\n$ forc plugins\nInstalled Plugins:\nforc-install\n```\n\n`forc-install` is a tool to manage GitHub dependencies in your Forc.toml file: For example, to install a sway library hosted on github:\n\n```console\nforc install https://github.com/user/sway-library\n```\n\nNote that some plugin crates can also provide more than one command. For example, installing the `forc-client` plugin provides the `forc deploy` and `forc run` commands. This is achieved by specifying multiple `[[bin]]` targets within the `forc-client` manifest.\n\n## Writing your own plugin\n\nWe encourage anyone to write and publish their own `forc` plugin to enhance their development experience.\n\nYour plugin must be named in the format `forc-` and you may use the above template as a starting point. You can use [clap](https://docs.rs/clap/latest/clap/) and add more subcommands, options and configurations to suit your plugin's needs.\n","forc-plugins/forc-debug/README.md":"# forc-debug\n\nDebugger attachable to FuelVM over a GraphQL API.\n\n## Testing\n\nThe automated tests assume that `fuel-core` binary is installed.\n","forc-plugins/forc-doc/README.md":"# Forc Doc\n\nThe Sway language documenter.\n\n---\n\n## Quick Start\n\n### Prerequisites\n\n- Must have [`forc`][forc-reference] installed.\n- Must be in a directory, or parent directory containing a [`Forc.toml`][manifest-reference] and some Sway code that successfully compiles\n- For documentation to appear you need only add doc attributes to documentable items, like so:\n ```sway\n /// Defines my contract ABI...\n abi MyContractABI {}\n ```\n- You may also document at the module level with the module level doc attribute syntax:\n > **Note:** This will only work at the beginning of Sway files\n ```sway\n //! Library containing types used for...\n library;\n ```\n Check out the [doc attribute section][sway-reference-attributes-doc] of the Sway reference for more information on how to document Sway code.\n\nIf you've installed a distributed toolchain via [`fuelup`][fuelup-docs], you already have everything you need to run `forc doc`. Otherwise, you can install `forc` & `forc doc` via `cargo install`, or from `fuelup` directly.\n\nThe below commands check you have everything necessary to run `forc doc`.\n\n```sh\n$ cd my_fuel_project\n$ ls # check Forc.toml exists\n# src Forc.toml\n$ forc --version # check forc is installed\n$ forc doc --version # check forc doc is installed\n$ forc doc --open # open docs in default browser\n```\n\nFor usage, [see the docs][forc-doc-manual].\n\nTo install `forc doc` for development, see the [Getting Started](#getting-started) section under [Contributing](#contributing).\n\n## Contributing\n\nWelcome! We're glad you're here to help. Below is an overview of the program's design choices, as well as how to build `forc doc` and test your changes locally.\n\n### Build Requirements\n\n- [`cargo`][install-cargo]\n- [`forc`][forc-reference]\n- a default, modern browser (older browsers may cause issues)\n\n> **Tip:** If you see no changes take effect, it may be due to multiple `forc doc` binaries. To prevent this, remove any pre-existing versions that take precedence, such as a `fuelup` binary. You can also avoid this by executing the `forc doc` binary via `cargo run`, see [Viewing Changes](#viewing-changes).\n>\n> ```sh\n> $ which forc-doc\n> # ~/.fuelup/bin/forc-doc\n> $ rm ~/.fuelup/bin/forc-doc\n> $ which forc-doc\n> # if it displays nothing, you're good to go!\n> ```\n\n### Getting Started\n\nClone the `sway` repository into your preferred directory:\n\n```sh\n$ git clone https://github.com/FuelLabs/sway.git\n```\n\nThen move into the newly created `sway` directory, and install `forc doc`:\n\n```sh\n$ cd sway\n$ cargo install --path forc-plugins/forc-doc\n```\n\nGreat! Let's check everything is working as intended. Try running `forc doc` on one of the test directories:\n\n```sh\n$ forc doc --path src/tests/data/impl_traits --open\n```\n\nIf it succeeded, you should be seeing the test docs in your browser.\n\n### Development\n\nNew language keyword? Want to add a feature? Updating CSS? `forc doc` is setup to make development easy.\n\n#### Design Overview\n\nEach section of the project is labeled to its corresponding functionality.\n\n- [`doc`](./src/doc/): The documenting phase. Handles analysis of a compiled typed Sway program and collects useful information into `Documents` that can be rendered to HTML. This is where to start if you are trying to implement a new Sway language feature, or make some information about an existing feature available for rendering.\n- [`render`](./src/render/): Renders the information collected by the documenting phase into HTML and places them into the `out/doc` directory. This phase is intended to be especially friendly to those familiar with building static HTML webpages. The [`horrorshow` library][horrorshow] uses macros to write HTML that look strikingly similar to writing plain HTML.\n- [`licenses`](./src/licenses/): Files that must be present in docs generated by `forc doc` for use of fonts, logos or anything pertaining to the project that requires a license.\n- [`static.files`](./src/static.files/): Files that must be present in docs generated by `forc doc` in order for styling to take effect, eg CSS, icons & fonts.\n- [`fixtures`](./tests/fixtures/): This is where edge case Sway code lives. If an edge case bug arises, write a minimal reproduction and place it here to start.\n\nTry running `cargo doc` on the `forc-doc` project directory for an in-depth look at what each section is responsible for!\n\n#### The Documenting Phase\n\n##### Documentable Items\n\nAdding new documentable items is very straight-forward. Documentable items take only two forms, declarations (`TyDecl`s) and context (everything else).\n\nDeclarations can be added directly to the description phase of the analysis, found in [`descriptor.rs`](./src/doc/descriptor.rs). Just add the new `TyDecl` to the match arm of `from_typed_decl` and fill in the necessary fields for the resulting `Descriptor` wrapped `Document`, then return it as `Documentable`.\n\nContext items, eg fields on structs, variants of an enum etc, must be added to the `ContextType` enum, found in [`context.rs`](./src/render/item/context.rs) and collected at the time of its corresponding `TyDecl`'s analysis. The `ContextType` is wrapped by a `Context` struct which is later sorted and rendered to the `ItemContext` of a `RenderedDocument`.\n\nExample:\n\nLet's say that we want to have a new declaration type called `CoolNewDecl`, modeled after the `StructDecl` but with some special purpose.\n\nFirst, we would add the context of the declaration to the `ContextType` as a variant:\n\n```rust\n// in context.rs\npub(crate) enum ContextType {\n // Add in the new declaration's context type\n CoolNewFields(Vec),\n /* ... */\n}\n```\n\nThen, match for the new declaration and return the `Document`.\n\n```rust\n// in descriptor.rs\npub(crate) enum Descriptor {\n Documentable(Document),\n NonDocumentable,\n}\nimpl Descriptor {\n pub(crate) fn from_typed_decl(/* ... */) -> Result {\n match ty_decl {\n // Add the new declaration to the match arm\n ty::TyDecl::CoolNewDecl(ty::CoolNewDecl { decl_id, .. }) => {\n let decl = decl_engine.get_cool_new_decl(decl_id);\n if !document_private_items && decl.visibility.is_private() {\n Ok(Descriptor::NonDocumentable)\n } else {\n let item_name = decl.call_path.suffix;\n let attrs_opt = (!decl.attributes.is_empty())\n .then(|| decl.attributes.to_html_string());\n // Fill in the context of the new declaration\n let context = (!decl.fields.is_empty()).then_some(Context::new(\n module_info.clone(),\n ContextType::CoolNewFields(decl.fields),\n ));\n\n Ok(Descriptor::Documentable(Document {\n module_info: module_info.clone(),\n item_header: ItemHeader {\n module_info: module_info.clone(),\n friendly_name: ty_decl.friendly_type_name(),\n item_name: item_name.clone(),\n },\n item_body: ItemBody {\n module_info,\n ty_decl: ty_decl.clone(),\n item_name,\n code_str: swayfmt::parse::parse_format::(\n decl.span.as_str(),\n )?,\n attrs_opt: attrs_opt.clone(),\n item_context: ItemContext {\n context_opt: context,\n impl_traits: None,\n },\n },\n raw_attributes: attrs_opt,\n }))\n }\n }\n /* ... */\n _ => Ok(Descriptor::NonDocumentable),\n }\n }\n}\n```\n\nOnce the declarations are collected into a `Document`, the `Document` can then be rendered. Refer to the `from_raw_docs` method on `RenderedDocumentation` found in [`render/mod.rs`](./src/render/mod.rs) for the beginning of the rendering phase. There you can find plenty of examples on how to render `Document`s into `RenderedDocument`s if you are adding in a new documentable item.\n\n##### Index File Generation\n\nIndex files, such as the `AllDocIndex`, `ProjectIndex` and `ModuleIndex`s, are rendered using only the information gathered from Sway modules. The process for their rendering can also be found in the `RenderedDocumentation::from_raw_docs` method. `ModuleInfo` is gathered from at point of generating the `Documentation` from a `TyProgram`, found in [`doc/mod.rs`](./src/doc/mod.rs). This is the starting point of the entire analytical process, where a `TyProgram` is compiled and passed to `Documentation::from_ty_program`.\n\n#### The Rendering Phase\n\nAs stated before, rendering is fairly straight-forward in `forc doc`, as the HTML is that of a generic webpage.\n\nLet's try writing a small render-side example together, using the `horrorshow` library.\n\nHere is the HTML for the search bar on [`docs.rs`][docs.rs]:\n\n```html\n\n```\n\nHere is the corresponding `horrorshow` code that produces the same HTML:\n\n```rust\nmod search {\n use horrorshow::{box_html, RenderBox};\n\n pub(crate) fn generate_searchbar() -> Box {\n box_html! {\n nav(class=\"sub\") {\n form(class=\"search-form\") {\n div(class=\"search-container\") {\n span;\n input(\n class=\"search-input\",\n name=\"search\",\n autocomplete=\"off\",\n spellcheck=\"false\",\n placeholder=\"Click or press ‘S’ to search, ‘?’ for more options…\",\n type=\"search\"\n );\n div(id=\"help-button\", title=\"help\", tabindex=\"-1\") {\n a(href=\"../help.html\") { : \"?\" }\n }\n div(id=\"settings-menu\", tabindex=\"-1\") {\n a(href=\"../settings.html\", title=\"settings\") {\n img(\n width=\"22\",\n height=\"22\",\n alt=\"change settings\",\n src=\"../static.files/wheel-7b819b6101059cd0.svg\"\n )\n }\n }\n }\n }\n }\n }\n }\n}\n```\n\nNow we can call this function anytime we need to generate a searchbar for our webpage!\n\n### Viewing Changes\n\nOnce you've made some changes, run the `forc doc` binary, passing it a path containing a `Forc.toml`:\n\n```sh\ncargo run -- --path path/to/manifest --open\n```\n\n> **Tip:** VS Code user? Try the Live Server plugin to make viewing changes even easier. It will reload a webpage on updates, so you only need to rebuild the docs (`cargo run -- --path path/to/manifest`). Just right click the index file of docs produced by `forc doc` which can be found in the `out/doc` directory, and choose the option \"open with Live Server\". Voila!\n\n[forc-reference]: https://fuellabs.github.io/sway/master/book/forc/index.html \"forc reference\"\n[manifest-reference]: https://fuellabs.github.io/sway/master/book/forc/manifest_reference.html \"manifest reference\"\n[sway-reference-attributes-doc]: https://fuellabs.github.io/sway/master/book/reference/attributes.html#doc \"the Sway reference - doc attribute usage\"\n[fuelup-docs]: https://install.fuel.network/master/ \"fuelup docs\"\n[forc-doc-manual]: https://fuellabs.github.io/sway/master/book/forc/plugins/forc_doc.html \"forc-doc manual\"\n[install-cargo]: https://doc.rust-lang.org/cargo/getting-started/installation.html \"install cargo\"\n[horrorshow]: https://docs.rs/horrorshow/latest/horrorshow/ \"horrorshow docs\"\n[docs.rs]: https://docs.rs/\n","forc-plugins/forc-doc/src/licenses/README.md":"# Assets Licenses Notice\n\nThis `licenses` directory contains all of the licenses associated with the assets contained within the [`static.files`](../static.files/) directory.\n","forc-plugins/forc-publish/README.md":"# forc-publish\n\nForc subcommand for uploading a package to the registry.\n\n## Authentication\n\nRequires either the `--token` argument to be passed, the environment variable `FORC_PUB_TOKEN`, or a `~/.forc/credentials.toml` file like this:\n\n```toml\n[registry]\ntoken = \"YOUR_TOKEN\"\n```\n\nThis credential file can be created automatically by running the CLI without the `--token` argument.\n\n## Local development\n\nFor local development, run [forc.pub](https://github.com/FuelLabs/forc.pub), create an API token and then `forc publish --registry-url http://localhost:8080`\n"},"files":{"docs/book/src/forc/commands/forc_add.md":"# forc add\n\nAdds one or more dependencies to a `Forc.toml` manifest.\n\n## **Usage**\n\n```bash\nforc add [OPTIONS] ...\n```\n\n## **Arguments**\n\n* ``: List of dependencies in the format `name[@version]` (e.g., `custom_lib@0.1.0`, `custom_contract`)\n\n## **Options**\n\n* `--path `: Add a local path dependency.\n* `--git `: Add a Git-based dependency.\n\n * Can be combined with one of:\n\n * `--branch `\n * `--tag `\n * `--rev `\n* `--ipfs `: Add a dependency sourced from IPFS.\n* `--contract-dep`: Add to `[contract-dependencies]` instead of `[dependencies]`.\n* `--salt `: Salt to use for contract deployment (only applies to contract dependencies).\n* `--package `: Apply change to a specific package in a workspace.\n* `--manifest-path `: Path to the `Forc.toml`.\n* `--dry-run`: Show what would be changed without writing to the file.\n* `--offline`: Do not fetch any remote dependencies.\n* `--ipfs-node `: IPFS node to use for IPFS-sourced dependencies.\n","docs/book/src/forc/commands/forc_addr2line.md":"# forc addr2line\n","docs/book/src/forc/commands/forc_build.md":"# forc build\n","docs/book/src/forc/commands/forc_check.md":"# forc check\n","docs/book/src/forc/commands/forc_clean.md":"# forc clean\n","docs/book/src/forc/commands/forc_completions.md":"# forc completions\n","docs/book/src/forc/commands/forc_contract-id.md":"# forc contract-id\n","docs/book/src/forc/commands/forc_init.md":"# forc init\n","docs/book/src/forc/commands/forc_new.md":"# forc new\n","docs/book/src/forc/commands/forc_parse-bytecode.md":"# forc parse-bytecode\n","docs/book/src/forc/commands/forc_plugins.md":"# forc plugins\n","docs/book/src/forc/commands/forc_predicate-root.md":"# forc predicate-root\n","docs/book/src/forc/commands/forc_remove.md":"# forc remove\n\nRemoves one or more dependencies from a `Forc.toml` manifest.\n\n## **Usage**\n\n```bash\nforc remove [OPTIONS] ...\n```\n\n## **Arguments**\n\n* ``: List of dependencies to remove by name (e.g., `custom_lib`, `custom_contract`)\n\n## **Options**\n\n* `--contract-dep`: Remove from `[contract-dependencies]` instead of `[dependencies]`.\n* `--package `: Target a specific package in a workspace.\n* `--manifest-path `: Path to the `Forc.toml`.\n* `--dry-run`: Preview what would be removed without making any changes.\n* `--offline`: Prevent forc from fetching metadata or resolving versions remotely.\n* `--ipfs-node `: IPFS node to use for reference.\n","docs/book/src/forc/commands/forc_template.md":"# forc template\n","docs/book/src/forc/commands/forc_test.md":"# forc test\n","docs/book/src/forc/commands/forc_update.md":"# forc update\n","docs/book/src/forc/commands/index.md":"\nHere are a list of commands available to forc:\n","docs/book/src/forc/plugins/forc_client/forc_call.md":"# forc call\n","docs/book/src/forc/plugins/forc_client/forc_deploy.md":"# forc deploy\n","docs/book/src/forc/plugins/forc_client/forc_run.md":"# forc run\n","docs/book/src/forc/plugins/forc_client/forc_submit.md":"# forc submit\n","docs/book/src/forc/plugins/forc_client/index.md":"# forc-client\n\nThe forc plugin for interacting with a Fuel node.\n\nSince transactions are going to require some gas, you need to sign them with an account that has enough coins to pay for them.\n\nWe offer multiple ways to sign the transaction:\n\n 1. Sign the transaction via your local wallet using `forc-client` which integrates with our CLI wallet, `forc-wallet`.\n 2. Use the default signer to deploy to a local node\n 3. Use `forc-wallet` to manually sign transactions, and copy the signed transaction back to `forc-client`.\n\nThe easiest and recommended way to interact with deployed networks such as our testnets is option 1, using `forc-client` to sign your transactions which reads your default `forc-wallet` vault. For interacting with local node, we recommend using the second option, which leads `forc-client` to sign transactions with the private key that comes pre-funded in local environments.\n\n## Option 1: Sign transactions via forc-client using your local forc-wallet vault\n\nIf you've used `forc-wallet` before, you'll already have a secure, password-protected vault holding your private key written to your file-system. `forc-client` is compatible with `forc-wallet` such that it can read that vault by asking you your password and use your account to sign transactions.\n\nExample:\n\n```console\n> forc deploy\n\n Building /Users/yourname/test-projects/test-contract\n Finished release [optimized + fuel] target(s) in 11.39s\n Confirming transactions [deploy impl-contract]\n Network: https://testnet.fuel.network\n Wallet: /Users/yourname/.fuel/wallets/.wallet\n✔ Wallet password · ********\n? Wallet account ›\n❯ [0] fuel12pls73y9hnqdqthvduy2x44x48zt8s50pkerf32kq26f2afeqdwq6rj9ar - 0.002197245 ETH\n [1] fuel1vzrm6kw9s3tv85gl25lpptsxrdguyzfhq6c8rk07tr6ft5g45nwqqh0uty - 0.001963631 ETH\n? Do you agree to sign 1 transaction? (y/n) › yes\n Finished deploying impl-contract https://app.fuel.network/contract/0x94b712901f04332682d14c998a5fc5a078ed15321438f46d58d0383200cde43d\n Deployed in block https://app.fuel.network/block/5958351\n```\n\nAs it can be seen from the example, `forc-client` asks for your password to decrypt the `forc-wallet` vault, and list your accounts so that you can select the one you want to fund the transaction with.\n\n## Option 2: Using default signer\n\nIf you are not interacting with a deployed network, such as testnets, your local `fuel-core` environment can be structured such that it funds an account by default. Using `--default-signer` flag with `forc-client` binaries (run, deploy) will instruct `forc-client` to sign transactions with this pre-funded account. This makes it a useful command while working against a local node.\n\nExample:\n\n```console\n> forc deploy --default-signer\n\n Building /Users/test/test-projects/test-contract\n Finished release [optimized + fuel] target(s) in 11.40s\n Confirming transactions [deploy impl-contract]\n Network: http://127.0.0.1:4000\n Finished deploying impl-contract 0xf9fb08ef18ce226954270d6d4f67677d484b8782a5892b3d436572b405407544\n Deployed in block 00000001\n```\n\n## Option 3: Manually signing through forc-wallet (Deprecated)\n\nThis option is for creating the transaction first, signing it manually, and supplying the signed transaction back to forc-client. Since it requires multiple steps, it is more error-prone and not recommended for general use cases. Also this will be deprecated soon.\n\n1. Construct the transaction by using either `forc deploy` or `forc run`. To do so simply run `forc deploy --manual-sign` or `forc run --manual-sign` with your desired parameters. For a list of parameters please refer to the [forc-deploy](./forc_deploy.md) or [forc-run](./forc_run.md) section of the book. Once you run either command you will be asked the address of the wallet you are going to be signing with. After the address is given the transaction will be generated and you will be given a transaction ID. At this point CLI will actively wait for you to insert the signature.\n2. Take the transaction ID generated in the first step and sign it with `forc wallet sign --account tx-id `. This will generate a signature.\n3. Take the signature generated in the second step and provide it to `forc-deploy` (or `forc-run`). Once the signature is provided, the signed transaction will be submitted.\n\n## Other useful commands of `forc-wallet`\n\n- You can see a list of existing accounts with `accounts` command.\n\n```sh\nforc wallet accounts\n```\n\n- If you want to retrieve the address for an account by its index you can use `account` command.\n\n```sh\nforc wallet account \n```\n\n> If you want to sign the transaction generated by `forc-deploy` or `forc-run` with an account funded by default once you start your local node, you can pass `--default-signer` to them. Please note that this will only work against your local node.\n>\n> ```sh\n> forc-deploy --default-signer\n> ```\n>\n> ```sh\n> forc-run --default-signer\n> ```\n\nBy default `--default-signer` flag would sign your transactions with the following private-key:\n\n```sh\n0xde97d8624a438121b86a1956544bd72ed68cd69f2c99555b08b1e8c51ffd511c\n```\n\n## Selecting a target network\n\nBy default, `local` is used for the target network. To interact with the latest testnet, use the `--testnet` flag. When this flag is passed, transactions created by `forc-deploy` will be sent to the latest `testnet`:\n\n```sh\nforc-deploy --testnet\n```\n\nThe same can be done to target mainnet:\n\n```sh\nforc-deploy --mainnet\n```\n\nIt is also possible to pass the exact node URL while using `forc-deploy` or `forc-run` which can be done using `--node-url` flag:\n\n```sh\nforc-deploy --node-url https://mainnet.fuel.network\n```\n\nAnother alternative is the `--target` option, which provides useful aliases to all targets. For example if you want to deploy to `testnet` you can use:\n\n```sh\nforc-deploy --target testnet\n```\n\nSince deploying and running projects on the testnet cost gas, you will need coins to pay for them. You can get some using the [testnet faucet](https://faucet-testnet.fuel.network/).\n\n## Delayed transactions\n\nFor delayed transactions, you can use the `--submit-only` flag. This flag allows you to submit the transaction without waiting for its finalization.\n\nOne use case for this is multisig transactions, where a deployment transaction may stay in a pending state while waiting for all signatures.\n\n```sh\nforc-deploy --submit-only\n```\n\n## Deployment Artifacts\n\nforc-deploy saves the details of each deployment in the `out/deployments` folder within the project's root directory. Below is an example of a deployment artifact:\n\n```json\n{\n \"transaction_id\": \"0xec27bb7a4c8a3b8af98070666cf4e6ea22ca4b9950a0862334a1830520012f5d\",\n \"salt\": \"0x9e35d1d5ef5724f29e649a3465033f5397d3ebb973c40a1d76bb35c253f0dec7\",\n \"network_endpoint\": \"http://127.0.0.1:4000\",\n \"chain_id\": 0,\n \"contract_id\": \"0x767eeaa7af2621e637f9785552620e175d4422b17d4cf0d76335c38808608a7b\",\n \"deployment_size\": 68,\n \"deployed_block_id\": \"0x915c6f372252be6bc54bd70df6362dae9bf750ba652bf5582d9b31c7023ca6cf\"\n}\n```\n\n## Proxy Contracts\n\n`forc-deploy` supports deploying proxy contracts automatically if it is enabled in the `Forc.toml` of the contract. This feature enables upgradeable contracts by deploying a proxy that forwards calls to an implementation contract, allowing you to upgrade the implementation without changing the proxy address.\n\n### Configuration\n\nTo enable proxy deployment, add a `[proxy]` table to your `Forc.toml`:\n\n```TOML\n[project]\nname = \"test_contract\"\nauthors = [\"Fuel Labs \"]\nentry = \"main.sw\"\nlicense = \"Apache-2.0\"\nimplicit-std = false\n\n[proxy]\nenabled = true\n```\n\nThe proxy configuration supports two fields:\n\n- `enabled` (boolean, required): Whether to deploy a proxy contract\n- `address` (string, optional): Address of an existing proxy contract to update\n\n### Fresh Proxy Deployment\n\nIf there is no `address` field present under the proxy table, like the example above, `forc` will automatically create a proxy contract based on the [SRC-14](https://github.com/FuelLabs/sway-standards/blob/master/docs/src/src-14-simple-upgradeable-proxies.md) implementation from [sway-standards](https://github.com/FuelLabs/sway-standards). The deployment process:\n\n1. **Deploy Implementation Contract**: Your contract is deployed as the implementation\n2. **Generate Proxy Contract**: A standard SRC-14 proxy contract is generated\n3. **Deploy Proxy Contract**: The proxy is deployed with your implementation as the target\n4. **Initialize Proxy**: The proxy is initialized with the deploying account as the owner\n5. **Update Manifest**: The proxy address is automatically added to your `Forc.toml`\n\nAfter deployment, you'll see output similar to:\n\n```console\nDeploying contract test_contract chunks\nFinished deploying test_contract 0x440b...925\nFinished deploying proxy contract for test_contract 0x19d4...f7\nInitialized proxy contract for test_contract\n```\n\nThe `Forc.toml` will be automatically updated with the proxy address:\n\n```TOML\n[proxy]\nenabled = true\naddress = \"0x19d465200575ebd085300242002efcda38db99e22449a5c1346588efe9ced7f7\"\n```\n\n### Updating Existing Proxy\n\nIf you want to update the target of an existing [SRC-14](https://github.com/FuelLabs/sway-standards/blob/master/docs/src/src-14-simple-upgradeable-proxies.md) compliant proxy contract, specify its address in the `address` field:\n\n```TOML\n[project]\nname = \"test_contract\"\nauthors = [\"Fuel Labs \"]\nentry = \"main.sw\"\nlicense = \"Apache-2.0\"\nimplicit-std = false\n\n[proxy]\nenabled = true\naddress = \"0xd8c4b07a0d1be57b228f4c18ba7bca0c8655eb6e9d695f14080f2cf4fc7cd946\" # example proxy contract address\n```\n\nWhen an `address` is present, `forc` will:\n\n1. Deploy the new implementation contract\n2. Call the existing proxy's `set_proxy_target` method to update the target\n3. The proxy address remains the same, providing seamless upgrades\n\n### Transaction Details\n\nWhen deploying with proxy enabled, you'll see multiple transactions in the confirmation:\n\n- One transaction to deploy the implementation contract\n- One additional transaction to deploy the proxy (for fresh deployments) or update the target (for existing proxies)\n\nExample output:\n\n```console\nConfirming transactions [deploy test_contract + deploy proxy]\nNetwork: https://testnet.fuel.network\n```\n\n### Storage Slots\n\nThe proxy contract includes both its own storage slots and preserves the storage slots from your implementation contract, ensuring that contract state is properly maintained across upgrades.\n\n### Important Notes\n\n- The proxy owner (initially set to the deploying account) has exclusive rights to update the proxy target\n- Once a proxy is deployed, the address in your `Forc.toml` allows for automatic target updates on subsequent deployments\n- Proxy contracts work with both regular and [chunked contracts](#large-contracts) (contracts over 100kB)\n- The implementation uses the SRC-14 standard for maximum compatibility with the Fuel ecosystem\n\n## Large Contracts\n\nFor contracts over the maximum contract size limit (currently `100kB`) defined by the network, `forc-deploy` will split the contract into chunks and deploy the contract with multiple transactions using the Rust SDK's [loader contract](https://github.com/FuelLabs/fuels-rs/blob/master/docs/src/deploying/large_contracts.md) functionality. Chunks that have already been deployed will be reused on subsequent deployments.\n\n## Deploying Scripts and Predicates\n\n`forc deploy` now supports deploying scripts and predicates in addition to contracts. These are deployed as blobs with generated loaders for efficiency.\n\nScripts and predicates are deployed automatically when you run `forc deploy` on a project that contains them. The deployment process differs slightly from contract deployment:\n\n1. For scripts and predicates, the bytecode is uploaded as a blob.\n2. A loader is generated that can load and execute the blob.\n3. The loader bytecode is saved in the project's output directory.\n\nAfter deployment, you'll find new files in your project's output directory:\n\n- For scripts: `-loader.bin`\n- For predicates: `-loader.bin` and `-loader-root`\n\nThe loader files contain the bytecode necessary to load and execute your script or predicate from the deployed blob.\n\nThis new deployment method allows for more efficient storage and execution of scripts and predicates on the Fuel network.\n\nNote: Contracts are still deployed directly, not as blobs given that the contract size is under the maximum contract size limit defined by network (currently `100kB`).\n","docs/book/src/forc/plugins/forc_crypto.md":"# forc crypto\n","docs/book/src/forc/plugins/forc_debug.md":"# forc debug\n","docs/book/src/forc/plugins/forc_doc.md":"# forc doc\n","docs/book/src/forc/plugins/forc_fmt.md":"# forc fmt\n","docs/book/src/forc/plugins/forc_lsp.md":"# forc lsp\n","docs/book/src/forc/plugins/forc_migrate.md":"# forc migrate\n","docs/book/src/forc/plugins/forc_node.md":"# forc node\n","docs/book/src/forc/plugins/forc_publish.md":"# forc publish\n","docs/book/src/forc/plugins/index.md":"# Plugins\n\nPlugins can be used to extend `forc` with new commands that go beyond the native commands mentioned in the previous chapter. While the Fuel ecosystem provides a few commonly useful plugins (`forc-fmt`, `forc-client`, `forc-lsp`, `forc-migrate`), anyone can write their own!\n\nLet's install a plugin, `forc-install`, and see what's underneath the plugin:\n\n```sh\ngit clone https://github.com/darthbenro008/forc-install\ncd forc-install\ncargo install --path .\n```\n\nCheck that we have installed `forc-install`:\n\n```console\n$ forc plugins\nInstalled Plugins:\nforc-install\n```\n\n`forc-install` is a tool to manage GitHub dependencies in your Forc.toml file: For example, to install a sway library hosted on github:\n\n```console\nforc install https://github.com/user/sway-library\n```\n\nNote that some plugin crates can also provide more than one command. For example, installing the `forc-client` plugin provides the `forc deploy` and `forc run` commands. This is achieved by specifying multiple `[[bin]]` targets within the `forc-client` manifest.\n\n## Writing your own plugin\n\nWe encourage anyone to write and publish their own `forc` plugin to enhance their development experience.\n\nYour plugin must be named in the format `forc-` and you may use the above template as a starting point. You can use [clap](https://docs.rs/clap/latest/clap/) and add more subcommands, options and configurations to suit your plugin's needs.\n","forc-plugins/forc-debug/README.md":"# forc-debug\n\nDebugger attachable to FuelVM over a GraphQL API.\n\n## Testing\n\nThe automated tests assume that `fuel-core` binary is installed.\n","forc-plugins/forc-doc/README.md":"# Forc Doc\n\nThe Sway language documenter.\n\n---\n\n## Quick Start\n\n### Prerequisites\n\n- Must have [`forc`][forc-reference] installed.\n- Must be in a directory, or parent directory containing a [`Forc.toml`][manifest-reference] and some Sway code that successfully compiles\n- For documentation to appear you need only add doc attributes to documentable items, like so:\n ```sway\n /// Defines my contract ABI...\n abi MyContractABI {}\n ```\n- You may also document at the module level with the module level doc attribute syntax:\n > **Note:** This will only work at the beginning of Sway files\n ```sway\n //! Library containing types used for...\n library;\n ```\n Check out the [doc attribute section][sway-reference-attributes-doc] of the Sway reference for more information on how to document Sway code.\n\nIf you've installed a distributed toolchain via [`fuelup`][fuelup-docs], you already have everything you need to run `forc doc`. Otherwise, you can install `forc` & `forc doc` via `cargo install`, or from `fuelup` directly.\n\nThe below commands check you have everything necessary to run `forc doc`.\n\n```sh\n$ cd my_fuel_project\n$ ls # check Forc.toml exists\n# src Forc.toml\n$ forc --version # check forc is installed\n$ forc doc --version # check forc doc is installed\n$ forc doc --open # open docs in default browser\n```\n\nFor usage, [see the docs][forc-doc-manual].\n\nTo install `forc doc` for development, see the [Getting Started](#getting-started) section under [Contributing](#contributing).\n\n## Contributing\n\nWelcome! We're glad you're here to help. Below is an overview of the program's design choices, as well as how to build `forc doc` and test your changes locally.\n\n### Build Requirements\n\n- [`cargo`][install-cargo]\n- [`forc`][forc-reference]\n- a default, modern browser (older browsers may cause issues)\n\n> **Tip:** If you see no changes take effect, it may be due to multiple `forc doc` binaries. To prevent this, remove any pre-existing versions that take precedence, such as a `fuelup` binary. You can also avoid this by executing the `forc doc` binary via `cargo run`, see [Viewing Changes](#viewing-changes).\n>\n> ```sh\n> $ which forc-doc\n> # ~/.fuelup/bin/forc-doc\n> $ rm ~/.fuelup/bin/forc-doc\n> $ which forc-doc\n> # if it displays nothing, you're good to go!\n> ```\n\n### Getting Started\n\nClone the `sway` repository into your preferred directory:\n\n```sh\n$ git clone https://github.com/FuelLabs/sway.git\n```\n\nThen move into the newly created `sway` directory, and install `forc doc`:\n\n```sh\n$ cd sway\n$ cargo install --path forc-plugins/forc-doc\n```\n\nGreat! Let's check everything is working as intended. Try running `forc doc` on one of the test directories:\n\n```sh\n$ forc doc --path src/tests/data/impl_traits --open\n```\n\nIf it succeeded, you should be seeing the test docs in your browser.\n\n### Development\n\nNew language keyword? Want to add a feature? Updating CSS? `forc doc` is setup to make development easy.\n\n#### Design Overview\n\nEach section of the project is labeled to its corresponding functionality.\n\n- [`doc`](./src/doc/): The documenting phase. Handles analysis of a compiled typed Sway program and collects useful information into `Documents` that can be rendered to HTML. This is where to start if you are trying to implement a new Sway language feature, or make some information about an existing feature available for rendering.\n- [`render`](./src/render/): Renders the information collected by the documenting phase into HTML and places them into the `out/doc` directory. This phase is intended to be especially friendly to those familiar with building static HTML webpages. The [`horrorshow` library][horrorshow] uses macros to write HTML that look strikingly similar to writing plain HTML.\n- [`licenses`](./src/licenses/): Files that must be present in docs generated by `forc doc` for use of fonts, logos or anything pertaining to the project that requires a license.\n- [`static.files`](./src/static.files/): Files that must be present in docs generated by `forc doc` in order for styling to take effect, eg CSS, icons & fonts.\n- [`fixtures`](./tests/fixtures/): This is where edge case Sway code lives. If an edge case bug arises, write a minimal reproduction and place it here to start.\n\nTry running `cargo doc` on the `forc-doc` project directory for an in-depth look at what each section is responsible for!\n\n#### The Documenting Phase\n\n##### Documentable Items\n\nAdding new documentable items is very straight-forward. Documentable items take only two forms, declarations (`TyDecl`s) and context (everything else).\n\nDeclarations can be added directly to the description phase of the analysis, found in [`descriptor.rs`](./src/doc/descriptor.rs). Just add the new `TyDecl` to the match arm of `from_typed_decl` and fill in the necessary fields for the resulting `Descriptor` wrapped `Document`, then return it as `Documentable`.\n\nContext items, eg fields on structs, variants of an enum etc, must be added to the `ContextType` enum, found in [`context.rs`](./src/render/item/context.rs) and collected at the time of its corresponding `TyDecl`'s analysis. The `ContextType` is wrapped by a `Context` struct which is later sorted and rendered to the `ItemContext` of a `RenderedDocument`.\n\nExample:\n\nLet's say that we want to have a new declaration type called `CoolNewDecl`, modeled after the `StructDecl` but with some special purpose.\n\nFirst, we would add the context of the declaration to the `ContextType` as a variant:\n\n```rust\n// in context.rs\npub(crate) enum ContextType {\n // Add in the new declaration's context type\n CoolNewFields(Vec),\n /* ... */\n}\n```\n\nThen, match for the new declaration and return the `Document`.\n\n```rust\n// in descriptor.rs\npub(crate) enum Descriptor {\n Documentable(Document),\n NonDocumentable,\n}\nimpl Descriptor {\n pub(crate) fn from_typed_decl(/* ... */) -> Result {\n match ty_decl {\n // Add the new declaration to the match arm\n ty::TyDecl::CoolNewDecl(ty::CoolNewDecl { decl_id, .. }) => {\n let decl = decl_engine.get_cool_new_decl(decl_id);\n if !document_private_items && decl.visibility.is_private() {\n Ok(Descriptor::NonDocumentable)\n } else {\n let item_name = decl.call_path.suffix;\n let attrs_opt = (!decl.attributes.is_empty())\n .then(|| decl.attributes.to_html_string());\n // Fill in the context of the new declaration\n let context = (!decl.fields.is_empty()).then_some(Context::new(\n module_info.clone(),\n ContextType::CoolNewFields(decl.fields),\n ));\n\n Ok(Descriptor::Documentable(Document {\n module_info: module_info.clone(),\n item_header: ItemHeader {\n module_info: module_info.clone(),\n friendly_name: ty_decl.friendly_type_name(),\n item_name: item_name.clone(),\n },\n item_body: ItemBody {\n module_info,\n ty_decl: ty_decl.clone(),\n item_name,\n code_str: swayfmt::parse::parse_format::(\n decl.span.as_str(),\n )?,\n attrs_opt: attrs_opt.clone(),\n item_context: ItemContext {\n context_opt: context,\n impl_traits: None,\n },\n },\n raw_attributes: attrs_opt,\n }))\n }\n }\n /* ... */\n _ => Ok(Descriptor::NonDocumentable),\n }\n }\n}\n```\n\nOnce the declarations are collected into a `Document`, the `Document` can then be rendered. Refer to the `from_raw_docs` method on `RenderedDocumentation` found in [`render/mod.rs`](./src/render/mod.rs) for the beginning of the rendering phase. There you can find plenty of examples on how to render `Document`s into `RenderedDocument`s if you are adding in a new documentable item.\n\n##### Index File Generation\n\nIndex files, such as the `AllDocIndex`, `ProjectIndex` and `ModuleIndex`s, are rendered using only the information gathered from Sway modules. The process for their rendering can also be found in the `RenderedDocumentation::from_raw_docs` method. `ModuleInfo` is gathered from at point of generating the `Documentation` from a `TyProgram`, found in [`doc/mod.rs`](./src/doc/mod.rs). This is the starting point of the entire analytical process, where a `TyProgram` is compiled and passed to `Documentation::from_ty_program`.\n\n#### The Rendering Phase\n\nAs stated before, rendering is fairly straight-forward in `forc doc`, as the HTML is that of a generic webpage.\n\nLet's try writing a small render-side example together, using the `horrorshow` library.\n\nHere is the HTML for the search bar on [`docs.rs`][docs.rs]:\n\n```html\n\n```\n\nHere is the corresponding `horrorshow` code that produces the same HTML:\n\n```rust\nmod search {\n use horrorshow::{box_html, RenderBox};\n\n pub(crate) fn generate_searchbar() -> Box {\n box_html! {\n nav(class=\"sub\") {\n form(class=\"search-form\") {\n div(class=\"search-container\") {\n span;\n input(\n class=\"search-input\",\n name=\"search\",\n autocomplete=\"off\",\n spellcheck=\"false\",\n placeholder=\"Click or press ‘S’ to search, ‘?’ for more options…\",\n type=\"search\"\n );\n div(id=\"help-button\", title=\"help\", tabindex=\"-1\") {\n a(href=\"../help.html\") { : \"?\" }\n }\n div(id=\"settings-menu\", tabindex=\"-1\") {\n a(href=\"../settings.html\", title=\"settings\") {\n img(\n width=\"22\",\n height=\"22\",\n alt=\"change settings\",\n src=\"../static.files/wheel-7b819b6101059cd0.svg\"\n )\n }\n }\n }\n }\n }\n }\n }\n}\n```\n\nNow we can call this function anytime we need to generate a searchbar for our webpage!\n\n### Viewing Changes\n\nOnce you've made some changes, run the `forc doc` binary, passing it a path containing a `Forc.toml`:\n\n```sh\ncargo run -- --path path/to/manifest --open\n```\n\n> **Tip:** VS Code user? Try the Live Server plugin to make viewing changes even easier. It will reload a webpage on updates, so you only need to rebuild the docs (`cargo run -- --path path/to/manifest`). Just right click the index file of docs produced by `forc doc` which can be found in the `out/doc` directory, and choose the option \"open with Live Server\". Voila!\n\n[forc-reference]: https://fuellabs.github.io/sway/master/book/forc/index.html \"forc reference\"\n[manifest-reference]: https://fuellabs.github.io/sway/master/book/forc/manifest_reference.html \"manifest reference\"\n[sway-reference-attributes-doc]: https://fuellabs.github.io/sway/master/book/reference/attributes.html#doc \"the Sway reference - doc attribute usage\"\n[fuelup-docs]: https://install.fuel.network/master/ \"fuelup docs\"\n[forc-doc-manual]: https://fuellabs.github.io/sway/master/book/forc/plugins/forc_doc.html \"forc-doc manual\"\n[install-cargo]: https://doc.rust-lang.org/cargo/getting-started/installation.html \"install cargo\"\n[horrorshow]: https://docs.rs/horrorshow/latest/horrorshow/ \"horrorshow docs\"\n[docs.rs]: https://docs.rs/\n","forc-plugins/forc-doc/src/licenses/README.md":"# Assets Licenses Notice\n\nThis `licenses` directory contains all of the licenses associated with the assets contained within the [`static.files`](../static.files/) directory.\n","forc-plugins/forc-publish/README.md":"# forc-publish\n\nForc subcommand for uploading a package to the registry.\n\n## Authentication\n\nRequires either the `--token` argument to be passed, the environment variable `FORC_PUB_TOKEN`, or a `~/.forc/credentials.toml` file like this:\n\n```toml\n[registry]\ntoken = \"YOUR_TOKEN\"\n```\n\nThis credential file can be created automatically by running the CLI without the `--token` argument.\n\n## Local development\n\nFor local development, run [forc.pub](https://github.com/FuelLabs/forc.pub), create an API token and then `forc publish --registry-url http://localhost:8080`\n"},"items":[{"name":"forc_call.md","path":"docs/book/src/forc/plugins/forc_client/forc_call.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/plugins/forc_client/forc_call.md","title":"Forc_client Skill","category":"anthropic-skill","format":"markdown","content":"# forc call\n","isInternal":false,"tokens":4,"sizeBytes":12},{"name":"forc_deploy.md","path":"docs/book/src/forc/plugins/forc_client/forc_deploy.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/plugins/forc_client/forc_deploy.md","title":"Forc_client Skill","category":"anthropic-skill","format":"markdown","content":"# forc deploy\n","isInternal":false,"tokens":4,"sizeBytes":14},{"name":"forc_run.md","path":"docs/book/src/forc/plugins/forc_client/forc_run.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/plugins/forc_client/forc_run.md","title":"Forc_client Skill","category":"anthropic-skill","format":"markdown","content":"# forc run\n","isInternal":false,"tokens":4,"sizeBytes":11},{"name":"forc_submit.md","path":"docs/book/src/forc/plugins/forc_client/forc_submit.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/plugins/forc_client/forc_submit.md","title":"Forc_client Skill","category":"anthropic-skill","format":"markdown","content":"# forc submit\n","isInternal":false,"tokens":4,"sizeBytes":14},{"name":"index.md","path":"docs/book/src/forc/plugins/forc_client/index.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/plugins/forc_client/index.md","title":"Forc_client Skill","category":"anthropic-skill","format":"markdown","content":"# forc-client\n\nThe forc plugin for interacting with a Fuel node.\n\nSince transactions are going to require some gas, you need to sign them with an account that has enough coins to pay for them.\n\nWe offer multiple ways to sign the transaction:\n\n 1. Sign the transaction via your local wallet using `forc-client` which integrates with our CLI wallet, `forc-wallet`.\n 2. Use the default signer to deploy to a local node\n 3. Use `forc-wallet` to manually sign transactions, and copy the signed transaction back to `forc-client`.\n\nThe easiest and recommended way to interact with deployed networks such as our testnets is option 1, using `forc-client` to sign your transactions which reads your default `forc-wallet` vault. For interacting with local node, we recommend using the second option, which leads `forc-client` to sign transactions with the private key that comes pre-funded in local environments.\n\n## Option 1: Sign transactions via forc-client using your local forc-wallet vault\n\nIf you've used `forc-wallet` before, you'll already have a secure, password-protected vault holding your private key written to your file-system. `forc-client` is compatible with `forc-wallet` such that it can read that vault by asking you your password and use your account to sign transactions.\n\nExample:\n\n```console\n> forc deploy\n\n Building /Users/yourname/test-projects/test-contract\n Finished release [optimized + fuel] target(s) in 11.39s\n Confirming transactions [deploy impl-contract]\n Network: https://testnet.fuel.network\n Wallet: /Users/yourname/.fuel/wallets/.wallet\n✔ Wallet password · ********\n? Wallet account ›\n❯ [0] fuel12pls73y9hnqdqthvduy2x44x48zt8s50pkerf32kq26f2afeqdwq6rj9ar - 0.002197245 ETH\n [1] fuel1vzrm6kw9s3tv85gl25lpptsxrdguyzfhq6c8rk07tr6ft5g45nwqqh0uty - 0.001963631 ETH\n? Do you agree to sign 1 transaction? (y/n) › yes\n Finished deploying impl-contract https://app.fuel.network/contract/0x94b712901f04332682d14c998a5fc5a078ed15321438f46d58d0383200cde43d\n Deployed in block https://app.fuel.network/block/5958351\n```\n\nAs it can be seen from the example, `forc-client` asks for your password to decrypt the `forc-wallet` vault, and list your accounts so that you can select the one you want to fund the transaction with.\n\n## Option 2: Using default signer\n\nIf you are not interacting with a deployed network, such as testnets, your local `fuel-core` environment can be structured such that it funds an account by default. Using `--default-signer` flag with `forc-client` binaries (run, deploy) will instruct `forc-client` to sign transactions with this pre-funded account. This makes it a useful command while working against a local node.\n\nExample:\n\n```console\n> forc deploy --default-signer\n\n Building /Users/test/test-projects/test-contract\n Finished release [optimized + fuel] target(s) in 11.40s\n Confirming transactions [deploy impl-contract]\n Network: http://127.0.0.1:4000\n Finished deploying impl-contract 0xf9fb08ef18ce226954270d6d4f67677d484b8782a5892b3d436572b405407544\n Deployed in block 00000001\n```\n\n## Option 3: Manually signing through forc-wallet (Deprecated)\n\nThis option is for creating the transaction first, signing it manually, and supplying the signed transaction back to forc-client. Since it requires multiple steps, it is more error-prone and not recommended for general use cases. Also this will be deprecated soon.\n\n1. Construct the transaction by using either `forc deploy` or `forc run`. To do so simply run `forc deploy --manual-sign` or `forc run --manual-sign` with your desired parameters. For a list of parameters please refer to the [forc-deploy](./forc_deploy.md) or [forc-run](./forc_run.md) section of the book. Once you run either command you will be asked the address of the wallet you are going to be signing with. After the address is given the transaction will be generated and you will be given a transaction ID. At this point CLI will actively wait for you to insert the signature.\n2. Take the transaction ID generated in the first step and sign it with `forc wallet sign --account tx-id `. This will generate a signature.\n3. Take the signature generated in the second step and provide it to `forc-deploy` (or `forc-run`). Once the signature is provided, the signed transaction will be submitted.\n\n## Other useful commands of `forc-wallet`\n\n- You can see a list of existing accounts with `accounts` command.\n\n```sh\nforc wallet accounts\n```\n\n- If you want to retrieve the address for an account by its index you can use `account` command.\n\n```sh\nforc wallet account \n```\n\n> If you want to sign the transaction generated by `forc-deploy` or `forc-run` with an account funded by default once you start your local node, you can pass `--default-signer` to them. Please note that this will only work against your local node.\n>\n> ```sh\n> forc-deploy --default-signer\n> ```\n>\n> ```sh\n> forc-run --default-signer\n> ```\n\nBy default `--default-signer` flag would sign your transactions with the following private-key:\n\n```sh\n0xde97d8624a438121b86a1956544bd72ed68cd69f2c99555b08b1e8c51ffd511c\n```\n\n## Selecting a target network\n\nBy default, `local` is used for the target network. To interact with the latest testnet, use the `--testnet` flag. When this flag is passed, transactions created by `forc-deploy` will be sent to the latest `testnet`:\n\n```sh\nforc-deploy --testnet\n```\n\nThe same can be done to target mainnet:\n\n```sh\nforc-deploy --mainnet\n```\n\nIt is also possible to pass the exact node URL while using `forc-deploy` or `forc-run` which can be done using `--node-url` flag:\n\n```sh\nforc-deploy --node-url https://mainnet.fuel.network\n```\n\nAnother alternative is the `--target` option, which provides useful aliases to all targets. For example if you want to deploy to `testnet` you can use:\n\n```sh\nforc-deploy --target testnet\n```\n\nSince deploying and running projects on the testnet cost gas, you will need coins to pay for them. You can get some using the [testnet faucet](https://faucet-testnet.fuel.network/).\n\n## Delayed transactions\n\nFor delayed transactions, you can use the `--submit-only` flag. This flag allows you to submit the transaction without waiting for its finalization.\n\nOne use case for this is multisig transactions, where a deployment transaction may stay in a pending state while waiting for all signatures.\n\n```sh\nforc-deploy --submit-only\n```\n\n## Deployment Artifacts\n\nforc-deploy saves the details of each deployment in the `out/deployments` folder within the project's root directory. Below is an example of a deployment artifact:\n\n```json\n{\n \"transaction_id\": \"0xec27bb7a4c8a3b8af98070666cf4e6ea22ca4b9950a0862334a1830520012f5d\",\n \"salt\": \"0x9e35d1d5ef5724f29e649a3465033f5397d3ebb973c40a1d76bb35c253f0dec7\",\n \"network_endpoint\": \"http://127.0.0.1:4000\",\n \"chain_id\": 0,\n \"contract_id\": \"0x767eeaa7af2621e637f9785552620e175d4422b17d4cf0d76335c38808608a7b\",\n \"deployment_size\": 68,\n \"deployed_block_id\": \"0x915c6f372252be6bc54bd70df6362dae9bf750ba652bf5582d9b31c7023ca6cf\"\n}\n```\n\n## Proxy Contracts\n\n`forc-deploy` supports deploying proxy contracts automatically if it is enabled in the `Forc.toml` of the contract. This feature enables upgradeable contracts by deploying a proxy that forwards calls to an implementation contract, allowing you to upgrade the implementation without changing the proxy address.\n\n### Configuration\n\nTo enable proxy deployment, add a `[proxy]` table to your `Forc.toml`:\n\n```TOML\n[project]\nname = \"test_contract\"\nauthors = [\"Fuel Labs \"]\nentry = \"main.sw\"\nlicense = \"Apache-2.0\"\nimplicit-std = false\n\n[proxy]\nenabled = true\n```\n\nThe proxy configuration supports two fields:\n\n- `enabled` (boolean, required): Whether to deploy a proxy contract\n- `address` (string, optional): Address of an existing proxy contract to update\n\n### Fresh Proxy Deployment\n\nIf there is no `address` field present under the proxy table, like the example above, `forc` will automatically create a proxy contract based on the [SRC-14](https://github.com/FuelLabs/sway-standards/blob/master/docs/src/src-14-simple-upgradeable-proxies.md) implementation from [sway-standards](https://github.com/FuelLabs/sway-standards). The deployment process:\n\n1. **Deploy Implementation Contract**: Your contract is deployed as the implementation\n2. **Generate Proxy Contract**: A standard SRC-14 proxy contract is generated\n3. **Deploy Proxy Contract**: The proxy is deployed with your implementation as the target\n4. **Initialize Proxy**: The proxy is initialized with the deploying account as the owner\n5. **Update Manifest**: The proxy address is automatically added to your `Forc.toml`\n\nAfter deployment, you'll see output similar to:\n\n```console\nDeploying contract test_contract chunks\nFinished deploying test_contract 0x440b...925\nFinished deploying proxy contract for test_contract 0x19d4...f7\nInitialized proxy contract for test_contract\n```\n\nThe `Forc.toml` will be automatically updated with the proxy address:\n\n```TOML\n[proxy]\nenabled = true\naddress = \"0x19d465200575ebd085300242002efcda38db99e22449a5c1346588efe9ced7f7\"\n```\n\n### Updating Existing Proxy\n\nIf you want to update the target of an existing [SRC-14](https://github.com/FuelLabs/sway-standards/blob/master/docs/src/src-14-simple-upgradeable-proxies.md) compliant proxy contract, specify its address in the `address` field:\n\n```TOML\n[project]\nname = \"test_contract\"\nauthors = [\"Fuel Labs \"]\nentry = \"main.sw\"\nlicense = \"Apache-2.0\"\nimplicit-std = false\n\n[proxy]\nenabled = true\naddress = \"0xd8c4b07a0d1be57b228f4c18ba7bca0c8655eb6e9d695f14080f2cf4fc7cd946\" # example proxy contract address\n```\n\nWhen an `address` is present, `forc` will:\n\n1. Deploy the new implementation contract\n2. Call the existing proxy's `set_proxy_target` method to update the target\n3. The proxy address remains the same, providing seamless upgrades\n\n### Transaction Details\n\nWhen deploying with proxy enabled, you'll see multiple transactions in the confirmation:\n\n- One transaction to deploy the implementation contract\n- One additional transaction to deploy the proxy (for fresh deployments) or update the target (for existing proxies)\n\nExample output:\n\n```console\nConfirming transactions [deploy test_contract + deploy proxy]\nNetwork: https://testnet.fuel.network\n```\n\n### Storage Slots\n\nThe proxy contract includes both its own storage slots and preserves the storage slots from your implementation contract, ensuring that contract state is properly maintained across upgrades.\n\n### Important Notes\n\n- The proxy owner (initially set to the deploying account) has exclusive rights to update the proxy target\n- Once a proxy is deployed, the address in your `Forc.toml` allows for automatic target updates on subsequent deployments\n- Proxy contracts work with both regular and [chunked contracts](#large-contracts) (contracts over 100kB)\n- The implementation uses the SRC-14 standard for maximum compatibility with the Fuel ecosystem\n\n## Large Contracts\n\nFor contracts over the maximum contract size limit (currently `100kB`) defined by the network, `forc-deploy` will split the contract into chunks and deploy the contract with multiple transactions using the Rust SDK's [loader contract](https://github.com/FuelLabs/fuels-rs/blob/master/docs/src/deploying/large_contracts.md) functionality. Chunks that have already been deployed will be reused on subsequent deployments.\n\n## Deploying Scripts and Predicates\n\n`forc deploy` now supports deploying scripts and predicates in addition to contracts. These are deployed as blobs with generated loaders for efficiency.\n\nScripts and predicates are deployed automatically when you run `forc deploy` on a project that contains them. The deployment process differs slightly from contract deployment:\n\n1. For scripts and predicates, the bytecode is uploaded as a blob.\n2. A loader is generated that can load and execute the blob.\n3. The loader bytecode is saved in the project's output directory.\n\nAfter deployment, you'll find new files in your project's output directory:\n\n- For scripts: `-loader.bin`\n- For predicates: `-loader.bin` and `-loader-root`\n\nThe loader files contain the bytecode necessary to load and execute your script or predicate from the deployed blob.\n\nThis new deployment method allows for more efficient storage and execution of scripts and predicates on the Fuel network.\n\nNote: Contracts are still deployed directly, not as blobs given that the contract size is under the maximum contract size limit defined by network (currently `100kB`).\n","isInternal":false,"tokens":3141,"sizeBytes":12748},{"name":"forc_crypto.md","path":"docs/book/src/forc/plugins/forc_crypto.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/plugins/forc_crypto.md","title":"Plugins Skill","category":"anthropic-skill","format":"markdown","content":"# forc crypto\n","isInternal":false,"tokens":4,"sizeBytes":14},{"name":"forc_debug.md","path":"docs/book/src/forc/plugins/forc_debug.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/plugins/forc_debug.md","title":"Plugins Skill","category":"anthropic-skill","format":"markdown","content":"# forc debug\n","isInternal":false,"tokens":4,"sizeBytes":13},{"name":"forc_doc.md","path":"docs/book/src/forc/plugins/forc_doc.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/plugins/forc_doc.md","title":"Plugins Skill","category":"anthropic-skill","format":"markdown","content":"# forc doc\n","isInternal":false,"tokens":4,"sizeBytes":11},{"name":"forc_fmt.md","path":"docs/book/src/forc/plugins/forc_fmt.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/plugins/forc_fmt.md","title":"Plugins Skill","category":"anthropic-skill","format":"markdown","content":"# forc fmt\n","isInternal":false,"tokens":4,"sizeBytes":11},{"name":"forc_lsp.md","path":"docs/book/src/forc/plugins/forc_lsp.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/plugins/forc_lsp.md","title":"Plugins Skill","category":"anthropic-skill","format":"markdown","content":"# forc lsp\n","isInternal":false,"tokens":4,"sizeBytes":11},{"name":"forc_migrate.md","path":"docs/book/src/forc/plugins/forc_migrate.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/plugins/forc_migrate.md","title":"Plugins Skill","category":"anthropic-skill","format":"markdown","content":"# forc migrate\n","isInternal":false,"tokens":4,"sizeBytes":15},{"name":"forc_node.md","path":"docs/book/src/forc/plugins/forc_node.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/plugins/forc_node.md","title":"Plugins Skill","category":"anthropic-skill","format":"markdown","content":"# forc node\n","isInternal":false,"tokens":4,"sizeBytes":12},{"name":"forc_publish.md","path":"docs/book/src/forc/plugins/forc_publish.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/plugins/forc_publish.md","title":"Plugins Skill","category":"anthropic-skill","format":"markdown","content":"# forc publish\n","isInternal":false,"tokens":4,"sizeBytes":15},{"name":"index.md","path":"docs/book/src/forc/plugins/index.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/plugins/index.md","title":"Plugins Skill","category":"anthropic-skill","format":"markdown","content":"# Plugins\n\nPlugins can be used to extend `forc` with new commands that go beyond the native commands mentioned in the previous chapter. While the Fuel ecosystem provides a few commonly useful plugins (`forc-fmt`, `forc-client`, `forc-lsp`, `forc-migrate`), anyone can write their own!\n\nLet's install a plugin, `forc-install`, and see what's underneath the plugin:\n\n```sh\ngit clone https://github.com/darthbenro008/forc-install\ncd forc-install\ncargo install --path .\n```\n\nCheck that we have installed `forc-install`:\n\n```console\n$ forc plugins\nInstalled Plugins:\nforc-install\n```\n\n`forc-install` is a tool to manage GitHub dependencies in your Forc.toml file: For example, to install a sway library hosted on github:\n\n```console\nforc install https://github.com/user/sway-library\n```\n\nNote that some plugin crates can also provide more than one command. For example, installing the `forc-client` plugin provides the `forc deploy` and `forc run` commands. This is achieved by specifying multiple `[[bin]]` targets within the `forc-client` manifest.\n\n## Writing your own plugin\n\nWe encourage anyone to write and publish their own `forc` plugin to enhance their development experience.\n\nYour plugin must be named in the format `forc-` and you may use the above template as a starting point. You can use [clap](https://docs.rs/clap/latest/clap/) and add more subcommands, options and configurations to suit your plugin's needs.\n","isInternal":false,"tokens":323,"sizeBytes":1433},{"name":"forc_add.md","path":"docs/book/src/forc/commands/forc_add.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/commands/forc_add.md","title":"Command: /forc_add","category":"command-prompt","format":"markdown","content":"# forc add\n\nAdds one or more dependencies to a `Forc.toml` manifest.\n\n## **Usage**\n\n```bash\nforc add [OPTIONS] ...\n```\n\n## **Arguments**\n\n* ``: List of dependencies in the format `name[@version]` (e.g., `custom_lib@0.1.0`, `custom_contract`)\n\n## **Options**\n\n* `--path `: Add a local path dependency.\n* `--git `: Add a Git-based dependency.\n\n * Can be combined with one of:\n\n * `--branch `\n * `--tag `\n * `--rev `\n* `--ipfs `: Add a dependency sourced from IPFS.\n* `--contract-dep`: Add to `[contract-dependencies]` instead of `[dependencies]`.\n* `--salt `: Salt to use for contract deployment (only applies to contract dependencies).\n* `--package `: Apply change to a specific package in a workspace.\n* `--manifest-path `: Path to the `Forc.toml`.\n* `--dry-run`: Show what would be changed without writing to the file.\n* `--offline`: Do not fetch any remote dependencies.\n* `--ipfs-node `: IPFS node to use for IPFS-sourced dependencies.\n","isInternal":false,"tokens":300,"sizeBytes":1044},{"name":"forc_addr2line.md","path":"docs/book/src/forc/commands/forc_addr2line.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/commands/forc_addr2line.md","title":"Command: /forc_addr2line","category":"command-prompt","format":"markdown","content":"# forc addr2line\n","isInternal":false,"tokens":6,"sizeBytes":17},{"name":"forc_build.md","path":"docs/book/src/forc/commands/forc_build.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/commands/forc_build.md","title":"Command: /forc_build","category":"command-prompt","format":"markdown","content":"# forc build\n","isInternal":false,"tokens":4,"sizeBytes":13},{"name":"forc_check.md","path":"docs/book/src/forc/commands/forc_check.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/commands/forc_check.md","title":"Command: /forc_check","category":"command-prompt","format":"markdown","content":"# forc check\n","isInternal":false,"tokens":4,"sizeBytes":13},{"name":"forc_clean.md","path":"docs/book/src/forc/commands/forc_clean.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/commands/forc_clean.md","title":"Command: /forc_clean","category":"command-prompt","format":"markdown","content":"# forc clean\n","isInternal":false,"tokens":4,"sizeBytes":13},{"name":"forc_completions.md","path":"docs/book/src/forc/commands/forc_completions.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/commands/forc_completions.md","title":"Command: /forc_completions","category":"command-prompt","format":"markdown","content":"# forc completions\n","isInternal":false,"tokens":5,"sizeBytes":19},{"name":"forc_contract-id.md","path":"docs/book/src/forc/commands/forc_contract-id.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/commands/forc_contract-id.md","title":"Command: /forc_contract-id","category":"command-prompt","format":"markdown","content":"# forc contract-id\n","isInternal":false,"tokens":5,"sizeBytes":19},{"name":"forc_init.md","path":"docs/book/src/forc/commands/forc_init.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/commands/forc_init.md","title":"Command: /forc_init","category":"command-prompt","format":"markdown","content":"# forc init\n","isInternal":false,"tokens":4,"sizeBytes":12},{"name":"forc_new.md","path":"docs/book/src/forc/commands/forc_new.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/commands/forc_new.md","title":"Command: /forc_new","category":"command-prompt","format":"markdown","content":"# forc new\n","isInternal":false,"tokens":4,"sizeBytes":11},{"name":"forc_parse-bytecode.md","path":"docs/book/src/forc/commands/forc_parse-bytecode.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/commands/forc_parse-bytecode.md","title":"Command: /forc_parse-bytecode","category":"command-prompt","format":"markdown","content":"# forc parse-bytecode\n","isInternal":false,"tokens":6,"sizeBytes":22},{"name":"forc_plugins.md","path":"docs/book/src/forc/commands/forc_plugins.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/commands/forc_plugins.md","title":"Command: /forc_plugins","category":"command-prompt","format":"markdown","content":"# forc plugins\n","isInternal":false,"tokens":4,"sizeBytes":15},{"name":"forc_predicate-root.md","path":"docs/book/src/forc/commands/forc_predicate-root.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/commands/forc_predicate-root.md","title":"Command: /forc_predicate-root","category":"command-prompt","format":"markdown","content":"# forc predicate-root\n","isInternal":false,"tokens":5,"sizeBytes":22},{"name":"forc_remove.md","path":"docs/book/src/forc/commands/forc_remove.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/commands/forc_remove.md","title":"Command: /forc_remove","category":"command-prompt","format":"markdown","content":"# forc remove\n\nRemoves one or more dependencies from a `Forc.toml` manifest.\n\n## **Usage**\n\n```bash\nforc remove [OPTIONS] ...\n```\n\n## **Arguments**\n\n* ``: List of dependencies to remove by name (e.g., `custom_lib`, `custom_contract`)\n\n## **Options**\n\n* `--contract-dep`: Remove from `[contract-dependencies]` instead of `[dependencies]`.\n* `--package `: Target a specific package in a workspace.\n* `--manifest-path `: Path to the `Forc.toml`.\n* `--dry-run`: Preview what would be removed without making any changes.\n* `--offline`: Prevent forc from fetching metadata or resolving versions remotely.\n* `--ipfs-node `: IPFS node to use for reference.\n","isInternal":false,"tokens":186,"sizeBytes":704},{"name":"forc_template.md","path":"docs/book/src/forc/commands/forc_template.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/commands/forc_template.md","title":"Command: /forc_template","category":"command-prompt","format":"markdown","content":"# forc template\n","isInternal":false,"tokens":4,"sizeBytes":16},{"name":"forc_test.md","path":"docs/book/src/forc/commands/forc_test.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/commands/forc_test.md","title":"Command: /forc_test","category":"command-prompt","format":"markdown","content":"# forc test\n","isInternal":false,"tokens":4,"sizeBytes":12},{"name":"forc_update.md","path":"docs/book/src/forc/commands/forc_update.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/commands/forc_update.md","title":"Command: /forc_update","category":"command-prompt","format":"markdown","content":"# forc update\n","isInternal":false,"tokens":4,"sizeBytes":14},{"name":"index.md","path":"docs/book/src/forc/commands/index.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/docs/book/src/forc/commands/index.md","title":"Command: /index","category":"command-prompt","format":"markdown","content":"\nHere are a list of commands available to forc:\n","isInternal":false,"tokens":17,"sizeBytes":83},{"name":"README.md","path":"forc-plugins/forc-debug/README.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/forc-plugins/forc-debug/README.md","title":"forc-debug Documentation","category":"plugin-manifest","format":"markdown","content":"# forc-debug\n\nDebugger attachable to FuelVM over a GraphQL API.\n\n## Testing\n\nThe automated tests assume that `fuel-core` binary is installed.\n","isInternal":false,"tokens":31,"sizeBytes":142},{"name":"README.md","path":"forc-plugins/forc-doc/README.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/forc-plugins/forc-doc/README.md","title":"forc-doc Documentation","category":"plugin-manifest","format":"markdown","content":"# Forc Doc\n\nThe Sway language documenter.\n\n---\n\n## Quick Start\n\n### Prerequisites\n\n- Must have [`forc`][forc-reference] installed.\n- Must be in a directory, or parent directory containing a [`Forc.toml`][manifest-reference] and some Sway code that successfully compiles\n- For documentation to appear you need only add doc attributes to documentable items, like so:\n ```sway\n /// Defines my contract ABI...\n abi MyContractABI {}\n ```\n- You may also document at the module level with the module level doc attribute syntax:\n > **Note:** This will only work at the beginning of Sway files\n ```sway\n //! Library containing types used for...\n library;\n ```\n Check out the [doc attribute section][sway-reference-attributes-doc] of the Sway reference for more information on how to document Sway code.\n\nIf you've installed a distributed toolchain via [`fuelup`][fuelup-docs], you already have everything you need to run `forc doc`. Otherwise, you can install `forc` & `forc doc` via `cargo install`, or from `fuelup` directly.\n\nThe below commands check you have everything necessary to run `forc doc`.\n\n```sh\n$ cd my_fuel_project\n$ ls # check Forc.toml exists\n# src Forc.toml\n$ forc --version # check forc is installed\n$ forc doc --version # check forc doc is installed\n$ forc doc --open # open docs in default browser\n```\n\nFor usage, [see the docs][forc-doc-manual].\n\nTo install `forc doc` for development, see the [Getting Started](#getting-started) section under [Contributing](#contributing).\n\n## Contributing\n\nWelcome! We're glad you're here to help. Below is an overview of the program's design choices, as well as how to build `forc doc` and test your changes locally.\n\n### Build Requirements\n\n- [`cargo`][install-cargo]\n- [`forc`][forc-reference]\n- a default, modern browser (older browsers may cause issues)\n\n> **Tip:** If you see no changes take effect, it may be due to multiple `forc doc` binaries. To prevent this, remove any pre-existing versions that take precedence, such as a `fuelup` binary. You can also avoid this by executing the `forc doc` binary via `cargo run`, see [Viewing Changes](#viewing-changes).\n>\n> ```sh\n> $ which forc-doc\n> # ~/.fuelup/bin/forc-doc\n> $ rm ~/.fuelup/bin/forc-doc\n> $ which forc-doc\n> # if it displays nothing, you're good to go!\n> ```\n\n### Getting Started\n\nClone the `sway` repository into your preferred directory:\n\n```sh\n$ git clone https://github.com/FuelLabs/sway.git\n```\n\nThen move into the newly created `sway` directory, and install `forc doc`:\n\n```sh\n$ cd sway\n$ cargo install --path forc-plugins/forc-doc\n```\n\nGreat! Let's check everything is working as intended. Try running `forc doc` on one of the test directories:\n\n```sh\n$ forc doc --path src/tests/data/impl_traits --open\n```\n\nIf it succeeded, you should be seeing the test docs in your browser.\n\n### Development\n\nNew language keyword? Want to add a feature? Updating CSS? `forc doc` is setup to make development easy.\n\n#### Design Overview\n\nEach section of the project is labeled to its corresponding functionality.\n\n- [`doc`](./src/doc/): The documenting phase. Handles analysis of a compiled typed Sway program and collects useful information into `Documents` that can be rendered to HTML. This is where to start if you are trying to implement a new Sway language feature, or make some information about an existing feature available for rendering.\n- [`render`](./src/render/): Renders the information collected by the documenting phase into HTML and places them into the `out/doc` directory. This phase is intended to be especially friendly to those familiar with building static HTML webpages. The [`horrorshow` library][horrorshow] uses macros to write HTML that look strikingly similar to writing plain HTML.\n- [`licenses`](./src/licenses/): Files that must be present in docs generated by `forc doc` for use of fonts, logos or anything pertaining to the project that requires a license.\n- [`static.files`](./src/static.files/): Files that must be present in docs generated by `forc doc` in order for styling to take effect, eg CSS, icons & fonts.\n- [`fixtures`](./tests/fixtures/): This is where edge case Sway code lives. If an edge case bug arises, write a minimal reproduction and place it here to start.\n\nTry running `cargo doc` on the `forc-doc` project directory for an in-depth look at what each section is responsible for!\n\n#### The Documenting Phase\n\n##### Documentable Items\n\nAdding new documentable items is very straight-forward. Documentable items take only two forms, declarations (`TyDecl`s) and context (everything else).\n\nDeclarations can be added directly to the description phase of the analysis, found in [`descriptor.rs`](./src/doc/descriptor.rs). Just add the new `TyDecl` to the match arm of `from_typed_decl` and fill in the necessary fields for the resulting `Descriptor` wrapped `Document`, then return it as `Documentable`.\n\nContext items, eg fields on structs, variants of an enum etc, must be added to the `ContextType` enum, found in [`context.rs`](./src/render/item/context.rs) and collected at the time of its corresponding `TyDecl`'s analysis. The `ContextType` is wrapped by a `Context` struct which is later sorted and rendered to the `ItemContext` of a `RenderedDocument`.\n\nExample:\n\nLet's say that we want to have a new declaration type called `CoolNewDecl`, modeled after the `StructDecl` but with some special purpose.\n\nFirst, we would add the context of the declaration to the `ContextType` as a variant:\n\n```rust\n// in context.rs\npub(crate) enum ContextType {\n // Add in the new declaration's context type\n CoolNewFields(Vec),\n /* ... */\n}\n```\n\nThen, match for the new declaration and return the `Document`.\n\n```rust\n// in descriptor.rs\npub(crate) enum Descriptor {\n Documentable(Document),\n NonDocumentable,\n}\nimpl Descriptor {\n pub(crate) fn from_typed_decl(/* ... */) -> Result {\n match ty_decl {\n // Add the new declaration to the match arm\n ty::TyDecl::CoolNewDecl(ty::CoolNewDecl { decl_id, .. }) => {\n let decl = decl_engine.get_cool_new_decl(decl_id);\n if !document_private_items && decl.visibility.is_private() {\n Ok(Descriptor::NonDocumentable)\n } else {\n let item_name = decl.call_path.suffix;\n let attrs_opt = (!decl.attributes.is_empty())\n .then(|| decl.attributes.to_html_string());\n // Fill in the context of the new declaration\n let context = (!decl.fields.is_empty()).then_some(Context::new(\n module_info.clone(),\n ContextType::CoolNewFields(decl.fields),\n ));\n\n Ok(Descriptor::Documentable(Document {\n module_info: module_info.clone(),\n item_header: ItemHeader {\n module_info: module_info.clone(),\n friendly_name: ty_decl.friendly_type_name(),\n item_name: item_name.clone(),\n },\n item_body: ItemBody {\n module_info,\n ty_decl: ty_decl.clone(),\n item_name,\n code_str: swayfmt::parse::parse_format::(\n decl.span.as_str(),\n )?,\n attrs_opt: attrs_opt.clone(),\n item_context: ItemContext {\n context_opt: context,\n impl_traits: None,\n },\n },\n raw_attributes: attrs_opt,\n }))\n }\n }\n /* ... */\n _ => Ok(Descriptor::NonDocumentable),\n }\n }\n}\n```\n\nOnce the declarations are collected into a `Document`, the `Document` can then be rendered. Refer to the `from_raw_docs` method on `RenderedDocumentation` found in [`render/mod.rs`](./src/render/mod.rs) for the beginning of the rendering phase. There you can find plenty of examples on how to render `Document`s into `RenderedDocument`s if you are adding in a new documentable item.\n\n##### Index File Generation\n\nIndex files, such as the `AllDocIndex`, `ProjectIndex` and `ModuleIndex`s, are rendered using only the information gathered from Sway modules. The process for their rendering can also be found in the `RenderedDocumentation::from_raw_docs` method. `ModuleInfo` is gathered from at point of generating the `Documentation` from a `TyProgram`, found in [`doc/mod.rs`](./src/doc/mod.rs). This is the starting point of the entire analytical process, where a `TyProgram` is compiled and passed to `Documentation::from_ty_program`.\n\n#### The Rendering Phase\n\nAs stated before, rendering is fairly straight-forward in `forc doc`, as the HTML is that of a generic webpage.\n\nLet's try writing a small render-side example together, using the `horrorshow` library.\n\nHere is the HTML for the search bar on [`docs.rs`][docs.rs]:\n\n```html\n\n```\n\nHere is the corresponding `horrorshow` code that produces the same HTML:\n\n```rust\nmod search {\n use horrorshow::{box_html, RenderBox};\n\n pub(crate) fn generate_searchbar() -> Box {\n box_html! {\n nav(class=\"sub\") {\n form(class=\"search-form\") {\n div(class=\"search-container\") {\n span;\n input(\n class=\"search-input\",\n name=\"search\",\n autocomplete=\"off\",\n spellcheck=\"false\",\n placeholder=\"Click or press ‘S’ to search, ‘?’ for more options…\",\n type=\"search\"\n );\n div(id=\"help-button\", title=\"help\", tabindex=\"-1\") {\n a(href=\"../help.html\") { : \"?\" }\n }\n div(id=\"settings-menu\", tabindex=\"-1\") {\n a(href=\"../settings.html\", title=\"settings\") {\n img(\n width=\"22\",\n height=\"22\",\n alt=\"change settings\",\n src=\"../static.files/wheel-7b819b6101059cd0.svg\"\n )\n }\n }\n }\n }\n }\n }\n }\n}\n```\n\nNow we can call this function anytime we need to generate a searchbar for our webpage!\n\n### Viewing Changes\n\nOnce you've made some changes, run the `forc doc` binary, passing it a path containing a `Forc.toml`:\n\n```sh\ncargo run -- --path path/to/manifest --open\n```\n\n> **Tip:** VS Code user? Try the Live Server plugin to make viewing changes even easier. It will reload a webpage on updates, so you only need to rebuild the docs (`cargo run -- --path path/to/manifest`). Just right click the index file of docs produced by `forc doc` which can be found in the `out/doc` directory, and choose the option \"open with Live Server\". Voila!\n\n[forc-reference]: https://fuellabs.github.io/sway/master/book/forc/index.html \"forc reference\"\n[manifest-reference]: https://fuellabs.github.io/sway/master/book/forc/manifest_reference.html \"manifest reference\"\n[sway-reference-attributes-doc]: https://fuellabs.github.io/sway/master/book/reference/attributes.html#doc \"the Sway reference - doc attribute usage\"\n[fuelup-docs]: https://install.fuel.network/master/ \"fuelup docs\"\n[forc-doc-manual]: https://fuellabs.github.io/sway/master/book/forc/plugins/forc_doc.html \"forc-doc manual\"\n[install-cargo]: https://doc.rust-lang.org/cargo/getting-started/installation.html \"install cargo\"\n[horrorshow]: https://docs.rs/horrorshow/latest/horrorshow/ \"horrorshow docs\"\n[docs.rs]: https://docs.rs/\n","isInternal":false,"tokens":2771,"sizeBytes":12868},{"name":"README.md","path":"forc-plugins/forc-doc/src/licenses/README.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/forc-plugins/forc-doc/src/licenses/README.md","title":"licenses Documentation","category":"plugin-manifest","format":"markdown","content":"# Assets Licenses Notice\n\nThis `licenses` directory contains all of the licenses associated with the assets contained within the [`static.files`](../static.files/) directory.\n","isInternal":false,"tokens":33,"sizeBytes":175},{"name":"README.md","path":"forc-plugins/forc-publish/README.md","rawUrl":"https://raw.githubusercontent.com/FuelLabs/sway/HEAD/forc-plugins/forc-publish/README.md","title":"forc-publish Documentation","category":"plugin-manifest","format":"markdown","content":"# forc-publish\n\nForc subcommand for uploading a package to the registry.\n\n## Authentication\n\nRequires either the `--token` argument to be passed, the environment variable `FORC_PUB_TOKEN`, or a `~/.forc/credentials.toml` file like this:\n\n```toml\n[registry]\ntoken = \"YOUR_TOKEN\"\n```\n\nThis credential file can be created automatically by running the CLI without the `--token` argument.\n\n## Local development\n\nFor local development, run [forc.pub](https://github.com/FuelLabs/forc.pub), create an API token and then `forc publish --registry-url http://localhost:8080`\n","isInternal":false,"tokens":134,"sizeBytes":565}],"systemPromptSnippet":"\n\n# forc call\n\n\n# forc deploy\n\n\n# forc run\n\n\n# forc submit\n\n\n# forc-client\n\nThe forc plugin for interacting with a Fuel node.\n\nSince transactions are going to require some gas, you need to sign them with an account that has enough coins to pay for them.\n\nWe offer multiple ways to sign the transaction:\n\n 1. Sign the transaction via your local wallet using `forc-client` which integrates with our CLI wallet, `forc-wallet`.\n 2. Use the default signer to deploy to a local node\n 3. Use `forc-wallet` to manually sign transactions, and copy the signed transaction back to `forc-client`.\n\nThe easiest and recommended way to interact with deployed networks such as our testnets is option 1, using `forc-client` to sign your transactions which reads your default `forc-wallet` vault. For interacting with local node, we recommend using the second option, which leads `forc-client` to sign transactions with the private key that comes pre-funded in local environments.\n\n## Option 1: Sign transactions via forc-client using your local forc-wallet vault\n\nIf you've used `forc-wallet` before, you'll already have a secure, password-protected vault holding your private key written to your file-system. `forc-client` is compatible with `forc-wallet` such that it can read that vault by asking you your password and use your account to sign transactions.\n\nExample:\n\n```console\n> forc deploy\n\n Building /Users/yourname/test-projects/test-contract\n Finished release [optimized + fuel] target(s) in 11.39s\n Confirming transactions [deploy impl-contract]\n Network: https://testnet.fuel.network\n Wallet: /Users/yourname/.fuel/wallets/.wallet\n✔ Wallet password · ********\n? Wallet account ›\n❯ [0] fuel12pls73y9hnqdqthvduy2x44x48zt8s50pkerf32kq26f2afeqdwq6rj9ar - 0.002197245 ETH\n [1] fuel1vzrm6kw9s3tv85gl25lpptsxrdguyzfhq6c8rk07tr6ft5g45nwqqh0uty - 0.001963631 ETH\n? Do you agree to sign 1 transaction? (y/n) › yes\n Finished deploying impl-contract https://app.fuel.network/contract/0x94b712901f04332682d14c998a5fc5a078ed15321438f46d58d0383200cde43d\n Deployed in block https://app.fuel.network/block/5958351\n```\n\nAs it can be seen from the example, `forc-client` asks for your password to decrypt the `forc-wallet` vault, and list your accounts so that you can select the one you want to fund the transaction with.\n\n## Option 2: Using default signer\n\nIf you are not interacting with a deployed network, such as testnets, your local `fuel-core` environment can be structured such that it funds an account by default. Using `--default-signer` flag with `forc-client` binaries (run, deploy) will instruct `forc-client` to sign transactions with this pre-funded account. This makes it a useful command while working against a local node.\n\nExample:\n\n```console\n> forc deploy --default-signer\n\n Building /Users/test/test-projects/test-contract\n Finished release [optimized + fuel] target(s) in 11.40s\n Confirming transactions [deploy impl-contract]\n Network: http://127.0.0.1:4000\n Finished deploying impl-contract 0xf9fb08ef18ce226954270d6d4f67677d484b8782a5892b3d436572b405407544\n Deployed in block 00000001\n```\n\n## Option 3: Manually signing through forc-wallet (Deprecated)\n\nThis option is for creating the transaction first, signing it manually, and supplying the signed transaction back to forc-client. Since it requires multiple steps, it is more error-prone and not recommended for general use cases. Also this will be deprecated soon.\n\n1. Construct the transaction by using either `forc deploy` or `forc run`. To do so simply run `forc deploy --manual-sign` or `forc run --manual-sign` with your desired parameters. For a list of parameters please refer to the [forc-deploy](./forc_deploy.md) or [forc-run](./forc_run.md) section of the book. Once you run either command you will be asked the address of the wallet you are going to be signing with. After the address is given the transaction will be generated and you will be given a transaction ID. At this point CLI will actively wait for you to insert the signature.\n2. Take the transaction ID generated in the first step and sign it with `forc wallet sign --account tx-id `. This will generate a signature.\n3. Take the signature generated in the second step and provide it to `forc-deploy` (or `forc-run`). Once the signature is provided, the signed transaction will be submitted.\n\n## Other useful commands of `forc-wallet`\n\n- You can see a list of existing accounts with `accounts` command.\n\n```sh\nforc wallet accounts\n```\n\n- If you want to retrieve the address for an account by its index you can use `account` command.\n\n```sh\nforc wallet account \n```\n\n> If you want to sign the transaction generated by `forc-deploy` or `forc-run` with an account funded by default once you start your local node, you can pass `--default-signer` to them. Please note that this will only work against your local node.\n>\n> ```sh\n> forc-deploy --default-signer\n> ```\n>\n> ```sh\n> forc-run --default-signer\n> ```\n\nBy default `--default-signer` flag would sign your transactions with the following private-key:\n\n```sh\n0xde97d8624a438121b86a1956544bd72ed68cd69f2c99555b08b1e8c51ffd511c\n```\n\n## Selecting a target network\n\nBy default, `local` is used for the target network. To interact with the latest testnet, use the `--testnet` flag. When this flag is passed, transactions created by `forc-deploy` will be sent to the latest `testnet`:\n\n```sh\nforc-deploy --testnet\n```\n\nThe same can be done to target mainnet:\n\n```sh\nforc-deploy --mainnet\n```\n\nIt is also possible to pass the exact node URL while using `forc-deploy` or `forc-run` which can be done using `--node-url` flag:\n\n```sh\nforc-deploy --node-url https://mainnet.fuel.network\n```\n\nAnother alternative is the `--target` option, which provides useful aliases to all targets. For example if you want to deploy to `testnet` you can use:\n\n```sh\nforc-deploy --target testnet\n```\n\nSince deploying and running projects on the testnet cost gas, you will need coins to pay for them. You can get some using the [testnet faucet](https://faucet-testnet.fuel.network/).\n\n## Delayed transactions\n\nFor delayed transactions, you can use the `--submit-only` flag. This flag allows you to submit the transaction without waiting for its finalization.\n\nOne use case for this is multisig transactions, where a deployment transaction may stay in a pending state while waiting for all signatures.\n\n```sh\nforc-deploy --submit-only\n```\n\n## Deployment Artifacts\n\nforc-deploy saves the details of each deployment in the `out/deployments` folder within the project's root directory. Below is an example of a deployment artifact:\n\n```json\n{\n \"transaction_id\": \"0xec27bb7a4c8a3b8af98070666cf4e6ea22ca4b9950a0862334a1830520012f5d\",\n \"salt\": \"0x9e35d1d5ef5724f29e649a3465033f5397d3ebb973c40a1d76bb35c253f0dec7\",\n \"network_endpoint\": \"http://127.0.0.1:4000\",\n \"chain_id\": 0,\n \"contract_id\": \"0x767eeaa7af2621e637f9785552620e175d4422b17d4cf0d76335c38808608a7b\",\n \"deployment_size\": 68,\n \"deployed_block_id\": \"0x915c6f372252be6bc54bd70df6362dae9bf750ba652bf5582d9b31c7023ca6cf\"\n}\n```\n\n## Proxy Contracts\n\n`forc-deploy` supports deploying proxy contracts automatically if it is enabled in the `Forc.toml` of the contract. This feature enables upgradeable contracts by deploying a proxy that forwards calls to an implementation contract, allowing you to upgrade the implementation without changing the proxy address.\n\n### Configuration\n\nTo enable proxy deployment, add a `[proxy]` table to your `Forc.toml`:\n\n```TOML\n[project]\nname = \"test_contract\"\nauthors = [\"Fuel Labs \"]\nentry = \"main.sw\"\nlicense = \"Apache-2.0\"\nimplicit-std = false\n\n[proxy]\nenabled = true\n```\n\nThe proxy configuration supports two fields:\n\n- `enabled` (boolean, required): Whether to deploy a proxy contract\n- `address` (string, optional): Address of an existing proxy contract to update\n\n### Fresh Proxy Deployment\n\nIf there is no `address` field present under the proxy table, like the example above, `forc` will automatically create a proxy contract based on the [SRC-14](https://github.com/FuelLabs/sway-standards/blob/master/docs/src/src-14-simple-upgradeable-proxies.md) implementation from [sway-standards](https://github.com/FuelLabs/sway-standards). The deployment process:\n\n1. **Deploy Implementation Contract**: Your contract is deployed as the implementation\n2. **Generate Proxy Contract**: A standard SRC-14 proxy contract is generated\n3. **Deploy Proxy Contract**: The proxy is deployed with your implementation as the target\n4. **Initialize Proxy**: The proxy is initialized with the deploying account as the owner\n5. **Update Manifest**: The proxy address is automatically added to your `Forc.toml`\n\nAfter deployment, you'll see output similar to:\n\n```console\nDeploying contract test_contract chunks\nFinished deploying test_contract 0x440b...925\nFinished deploying proxy contract for test_contract 0x19d4...f7\nInitialized proxy contract for test_contract\n```\n\nThe `Forc.toml` will be automatically updated with the proxy address:\n\n```TOML\n[proxy]\nenabled = true\naddress = \"0x19d465200575ebd085300242002efcda38db99e22449a5c1346588efe9ced7f7\"\n```\n\n### Updating Existing Proxy\n\nIf you want to update the target of an existing [SRC-14](https://github.com/FuelLabs/sway-standards/blob/master/docs/src/src-14-simple-upgradeable-proxies.md) compliant proxy contract, specify its address in the `address` field:\n\n```TOML\n[project]\nname = \"test_contract\"\nauthors = [\"Fuel Labs \"]\nentry = \"main.sw\"\nlicense = \"Apache-2.0\"\nimplicit-std = false\n\n[proxy]\nenabled = true\naddress = \"0xd8c4b07a0d1be57b228f4c18ba7bca0c8655eb6e9d695f14080f2cf4fc7cd946\" # example proxy contract address\n```\n\nWhen an `address` is present, `forc` will:\n\n1. Deploy the new implementation contract\n2. Call the existing proxy's `set_proxy_target` method to update the target\n3. The proxy address remains the same, providing seamless upgrades\n\n### Transaction Details\n\nWhen deploying with proxy enabled, you'll see multiple transactions in the confirmation:\n\n- One transaction to deploy the implementation contract\n- One additional transaction to deploy the proxy (for fresh deployments) or update the target (for existing proxies)\n\nExample output:\n\n```console\nConfirming transactions [deploy test_contract + deploy proxy]\nNetwork: https://testnet.fuel.network\n```\n\n### Storage Slots\n\nThe proxy contract includes both its own storage slots and preserves the storage slots from your implementation contract, ensuring that contract state is properly maintained across upgrades.\n\n### Important Notes\n\n- The proxy owner (initially set to the deploying account) has exclusive rights to update the proxy target\n- Once a proxy is deployed, the address in your `Forc.toml` allows for automatic target updates on subsequent deployments\n- Proxy contracts work with both regular and [chunked contracts](#large-contracts) (contracts over 100kB)\n- The implementation uses the SRC-14 standard for maximum compatibility with the Fuel ecosystem\n\n## Large Contracts\n\nFor contracts over the maximum contract size limit (currently `100kB`) defined by the network, `forc-deploy` will split the contract into chunks and deploy the contract with multiple transactions using the Rust SDK's [loader contract](https://github.com/FuelLabs/fuels-rs/blob/master/docs/src/deploying/large_contracts.md) functionality. Chunks that have already been deployed will be reused on subsequent deployments.\n\n## Deploying Scripts and Predicates\n\n`forc deploy` now supports deploying scripts and predicates in addition to contracts. These are deployed as blobs with generated loaders for efficiency.\n\nScripts and predicates are deployed automatically when you run `forc deploy` on a project that contains them. The deployment process differs slightly from contract deployment:\n\n1. For scripts and predicates, the bytecode is uploaded as a blob.\n2. A loader is generated that can load and execute the blob.\n3. The loader bytecode is saved in the project's output directory.\n\nAfter deployment, you'll find new files in your project's output directory:\n\n- For scripts: `-loader.bin`\n- For predicates: `-loader.bin` and `-loader-root`\n\nThe loader files contain the bytecode necessary to load and execute your script or predicate from the deployed blob.\n\nThis new deployment method allows for more efficient storage and execution of scripts and predicates on the Fuel network.\n\nNote: Contracts are still deployed directly, not as blobs given that the contract size is under the maximum contract size limit defined by network (currently `100kB`).\n\n\n# forc crypto\n\n\n# forc debug\n\n\n# forc doc\n\n\n# forc fmt\n\n\n# forc lsp\n\n\n# forc migrate\n\n\n# forc node\n\n\n# forc publish\n\n\n# Plugins\n\nPlugins can be used to extend `forc` with new commands that go beyond the native commands mentioned in the previous chapter. While the Fuel ecosystem provides a few commonly useful plugins (`forc-fmt`, `forc-client`, `forc-lsp`, `forc-migrate`), anyone can write their own!\n\nLet's install a plugin, `forc-install`, and see what's underneath the plugin:\n\n```sh\ngit clone https://github.com/darthbenro008/forc-install\ncd forc-install\ncargo install --path .\n```\n\nCheck that we have installed `forc-install`:\n\n```console\n$ forc plugins\nInstalled Plugins:\nforc-install\n```\n\n`forc-install` is a tool to manage GitHub dependencies in your Forc.toml file: For example, to install a sway library hosted on github:\n\n```console\nforc install https://github.com/user/sway-library\n```\n\nNote that some plugin crates can also provide more than one command. For example, installing the `forc-client` plugin provides the `forc deploy` and `forc run` commands. This is achieved by specifying multiple `[[bin]]` targets within the `forc-client` manifest.\n\n## Writing your own plugin\n\nWe encourage anyone to write and publish their own `forc` plugin to enhance their development experience.\n\nYour plugin must be named in the format `forc-` and you may use the above template as a starting point. You can use [clap](https://docs.rs/clap/latest/clap/) and add more subcommands, options and configurations to suit your plugin's needs.\n\n\n# forc add\n\nAdds one or more dependencies to a `Forc.toml` manifest.\n\n## **Usage**\n\n```bash\nforc add [OPTIONS] ...\n```\n\n## **Arguments**\n\n* ``: List of dependencies in the format `name[@version]` (e.g., `custom_lib@0.1.0`, `custom_contract`)\n\n## **Options**\n\n* `--path `: Add a local path dependency.\n* `--git `: Add a Git-based dependency.\n\n * Can be combined with one of:\n\n * `--branch `\n * `--tag `\n * `--rev `\n* `--ipfs `: Add a dependency sourced from IPFS.\n* `--contract-dep`: Add to `[contract-dependencies]` instead of `[dependencies]`.\n* `--salt `: Salt to use for contract deployment (only applies to contract dependencies).\n* `--package `: Apply change to a specific package in a workspace.\n* `--manifest-path `: Path to the `Forc.toml`.\n* `--dry-run`: Show what would be changed without writing to the file.\n* `--offline`: Do not fetch any remote dependencies.\n* `--ipfs-node `: IPFS node to use for IPFS-sourced dependencies.\n\n\n# forc addr2line\n\n\n# forc build\n\n\n# forc check\n\n\n# forc clean\n\n\n# forc completions\n\n\n# forc contract-id\n\n\n# forc init\n\n\n# forc new\n\n\n# forc parse-bytecode\n\n\n# forc plugins\n\n\n# forc predicate-root\n\n\n# forc remove\n\nRemoves one or more dependencies from a `Forc.toml` manifest.\n\n## **Usage**\n\n```bash\nforc remove [OPTIONS] ...\n```\n\n## **Arguments**\n\n* ``: List of dependencies to remove by name (e.g., `custom_lib`, `custom_contract`)\n\n## **Options**\n\n* `--contract-dep`: Remove from `[contract-dependencies]` instead of `[dependencies]`.\n* `--package `: Target a specific package in a workspace.\n* `--manifest-path `: Path to the `Forc.toml`.\n* `--dry-run`: Preview what would be removed without making any changes.\n* `--offline`: Prevent forc from fetching metadata or resolving versions remotely.\n* `--ipfs-node `: IPFS node to use for reference.\n\n\n# forc template\n\n\n# forc test\n\n\n# forc update\n\n\n"}