You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: docs/book/src/forc/manifest_reference.md
+78
Original file line number
Diff line number
Diff line change
@@ -11,6 +11,7 @@ The `Forc.toml` (the _manifest_ file) is a compulsory file for each package and
11
11
* For the recommended way of selecting an entry point of large libraries please take a look at: [Libraries](./../sway-program-types/libraries.md)
12
12
*`implicit-std` - Controls whether provided `std` version (with the current `forc` version) will get added as a dependency _implicitly_. _Unless you know what you are doing, leave this as default._
13
13
*`forc-version` - The minimum forc version required for this project to work properly.
14
+
*`metadata` - Metadata for the project; can be used by tools which would like to store package configuration in `Forc.toml`.
14
15
15
16
*[`[dependencies]`](#the-dependencies-section) — Defines the dependencies.
16
17
*`[network]` — Defines a network for forc to interact with.
The `[project.metadata]` section provides a dedicated space for external tools and plugins to store their configuration in `Forc.toml`. The metadata key names are arbitrary and do not need to match the tool's name.
53
+
54
+
#### Workspace vs Project Metadata
55
+
56
+
Metadata can be defined at two levels:
57
+
58
+
Workspace level - defined in the workspace\'s root `Forc.toml`:
59
+
60
+
```toml
61
+
[workspace.metadata]
62
+
my_tool = { shared_setting = "value" }
63
+
```
64
+
65
+
Project level - defined in individual project\'s `Forc.toml`:
* Project-level metadata should take precedence over workspace metadata
88
+
* Tools can choose to merge workspace and project settings
89
+
* Consider documenting your tool's metadata inheritance behavior
90
+
91
+
#### Guidelines for Plugin Developers
92
+
93
+
Best Practices
94
+
95
+
* Choose clear, descriptive metadata key names
96
+
* Document the exact metadata key name your tool expects
97
+
* Don't require `Forc.toml` if tool can function without it
98
+
* Consider using TOML format for dedicated config files
99
+
* Specify how your tool handles workspace vs project metadata
100
+
101
+
Implementation Notes
102
+
103
+
* The metadata section is optional
104
+
* Forc does not parse metadata contents
105
+
* Plugin developers handle their own configuration parsing
106
+
* Choose unique metadata keys to avoid conflicts with other tools
107
+
108
+
#### Example Use Cases
109
+
110
+
* Documentation generation settings
111
+
* Formatter configurations
112
+
* Debugger options
113
+
* Wallet integration
114
+
* Contract indexing
115
+
* Testing frameworks
116
+
117
+
This allows for a streamlined developer experience while maintaining clear separation between core Forc functionality and third-party tools.
118
+
119
+
#### External Tooling Examples
120
+
121
+
*[forc-index-ts](https://github.com/FuelLabs/example-forc-plugins/tree/master/forc-index-ts): A TypeScript CLI tool for parsing `Forc.toml` metadata to read contract ABI JSON file.
122
+
*[forc-index-rs](https://github.com/FuelLabs/example-forc-plugins/tree/master/forc-index-rs): A Rust CLI tool for parsing `Forc.toml` metadata to read contract ABI JSON file.
123
+
46
124
## The `[dependencies]` section
47
125
48
126
The following fields can be provided with a dependency:
0 commit comments