|
| 1 | +<!-- markdownlint-disable MD041 --> |
| 2 | + |
| 3 | +# Migrating Sway projects |
| 4 | + |
| 5 | +`forc-migrate` guides you through breaking changes between Sway versions. It fully or semiautomatically adapts your code, making it compatible with the next breaking change version of Sway. |
| 6 | + |
| 7 | +`forc-migrate` migrates the code to the _next_ breaking change version of Sway. That means, if you want to migrate to, e.g., Sway v0.**67**.0, you will need to use the _latest v0.**66**.x_ version of the `forc-migrate`. |
| 8 | + |
| 9 | +For example, let's say that your Sway project is on the version _v0.66.1_, and that the latest v0.66 version is _v0.66.42_. You should first update your Fuel toolchain to the version _v0.66.42_ of `forc`, and compile your project with that version: |
| 10 | + |
| 11 | +```text |
| 12 | +fuelup component add forc@0.66.42 |
| 13 | +``` |
| 14 | + |
| 15 | +Sway guarantees that all the versions with the same minor version, _0.66_ in the above example, are compatible. That means that the latest patch version, _0.66.42_ in the example, will correctly compile your project. |
| 16 | + |
| 17 | +## Showing the breaking changes |
| 18 | + |
| 19 | +Once you've installed the latest non-breaking version of `forc-migrate`, use the `show` command to make yourself familiar with the upcoming breaking changes: |
| 20 | + |
| 21 | +```text |
| 22 | +forc migrate show |
| 23 | +``` |
| 24 | + |
| 25 | +A typical output of the `show` command will look like this: |
| 26 | + |
| 27 | +```text |
| 28 | +Breaking change features: |
| 29 | + - storage_domains (https://github.com/FuelLabs/sway/issues/6701) |
| 30 | + - references (https://github.com/FuelLabs/sway/issues/5063) |
| 31 | +
|
| 32 | +Migration steps (1 manual and 1 semiautomatic): |
| 33 | +storage_domains |
| 34 | + [M] Review explicitly defined slot keys in storage declarations (`in` keywords) |
| 35 | +
|
| 36 | +references |
| 37 | + [S] Replace `ref mut` function parameters with `&mut` |
| 38 | +
|
| 39 | +Experimental feature flags: |
| 40 | +- for Forc.toml: experimental = { storage_domains = true, references = true } |
| 41 | +- for CLI: --experimental storage_domains,references |
| 42 | +``` |
| 43 | + |
| 44 | +The output will contain: |
| 45 | + |
| 46 | +- the upcoming breaking change features, `storage_domains` and `references` in this example, |
| 47 | +- their tracking issues on GitHub, with detailed migration guides, |
| 48 | +- and the migration steps potentially required to migrate existing code. |
| 49 | + |
| 50 | +The migration steps can be _manual_, _semiautomatic_, or fully _automatic_. They are marked in the output with `[M]`, `[S]`, and `[A]`, respectively. |
| 51 | + |
| 52 | +The `show` command will also provide experimental feature flags that will be needed during the migration, as explained in the next chapter. |
| 53 | + |
| 54 | +## Migrating a single Sway project |
| 55 | + |
| 56 | +Let's assume that we want to migrate a Sway project called `my_project` that depends on `std` and a `third_party_lib`. |
| 57 | + |
| 58 | +First, we will go to the folder that contains `my_project`, e.g.: `cd my_project`. All of the upcoming CLI commands assume that we are running the `forc-migrate` tool within the `my_project` folder. |
| 59 | + |
| 60 | +Before migrating the code, make sure that the project builds without any errors by running: |
| 61 | + |
| 62 | +```text |
| 63 | +forc build |
| 64 | +``` |
| 65 | + |
| 66 | +### Check the migration summary |
| 67 | + |
| 68 | +Next, let's `check` the project first. The `check` command will dry-run the migration steps. It will not do any changes in code, but will provide a detailed information of all the places in code that need to be either reviewed or changed during the migration process. The `check` command will also provide a rough time estimate for the migration. |
| 69 | + |
| 70 | +```text |
| 71 | +forc migrate check |
| 72 | +``` |
| 73 | + |
| 74 | +The output of the `check` command will end in a summary of the migration effort, containing: |
| 75 | + |
| 76 | +- the number of occurrences of a particular migration step in the project's code, |
| 77 | +- the rough migration effort estimate for each migration step, |
| 78 | +- and the rough total migration effort. |
| 79 | + |
| 80 | +```text |
| 81 | +Migration effort: |
| 82 | +
|
| 83 | +storage_domains |
| 84 | + [M] Review explicitly defined slot keys in storage declarations (`in` keywords) |
| 85 | + Occurrences: 3 Migration effort (hh::mm): ~00:06 |
| 86 | +
|
| 87 | +references |
| 88 | + [S] Replace `ref mut` function parameters with `&mut` |
| 89 | + Occurrences: 18 Migration effort (hh::mm): ~01:30 |
| 90 | +
|
| 91 | +Total migration effort (hh::mm): ~01:36 |
| 92 | +``` |
| 93 | + |
| 94 | +Before the summary, instructions will be shown for each migration step. A typical instruction output for a single migration step will contain: |
| 95 | + |
| 96 | +- the name of the step, |
| 97 | +- the places in code affected by the migration step, |
| 98 | +- and the short help with a link to the detailed migration guide. |
| 99 | + |
| 100 | +```text |
| 101 | +info: [references] Replace `ref mut` function parameters with `&mut` |
| 102 | + --> my_project/src/main.sw:30:51 |
| 103 | + | |
| 104 | +... |
| 105 | +30 | fn ref_mut_fn(ref mut x: u64) {} |
| 106 | + | --------- |
| 107 | +... |
| 108 | +35 | fn another_ref_mut_fn(ref mut arg: S) {} |
| 109 | + | ----------- |
| 110 | + | |
| 111 | + = help: Migration will replace `ref mut` function parameters with `&mut`. |
| 112 | + = help: E.g., `ref mut x: u64` will become `x: &mut u64`. |
| 113 | + = help: |
| 114 | + = help: After the migration, you will still need to: |
| 115 | + = help: - change function callers, by adding `&mut` to passed parameters. |
| 116 | + = help: - change function bodies, by dereferencing (`*`) parameters where needed. |
| 117 | + = help: |
| 118 | + = help: For a detailed migration guide see: https://github.com/FuelLabs/sway/issues/5063 |
| 119 | +``` |
| 120 | + |
| 121 | +### Update dependencies |
| 122 | + |
| 123 | +Before running the migrations on the project itself, **first update the project dependencies to the versions that use the next Sway breaking change version**. |
| 124 | + |
| 125 | +In our example, the `my_project`'s `Forc.toml` file will have the `[dependencies]` section similar to this one: |
| 126 | + |
| 127 | +```toml |
| 128 | +[dependencies] |
| 129 | +std = { git = "https://github.com/FuelLabs/sway", tag = "v0.66.1" } |
| 130 | +third_party_lib = { git = "https://github.com/ThirdParty/swaylib", tag = "v1.0.0" } |
| 131 | +``` |
| 132 | + |
| 133 | +Assuming that the `third_party_lib` version compatible with Sway v0.67.0 is the version v2.0.0 we will end up in the following changes: |
| 134 | + |
| 135 | +```toml |
| 136 | +[dependencies] |
| 137 | +# Changed v0.66.1 -> v0.67.0 |
| 138 | +std = { git = "https://github.com/FuelLabs/sway", tag = "v0.67.0" } |
| 139 | +# Changed v1.0.0 -> v2.0.0 |
| 140 | +third_party_lib = { git = "https://github.com/ThirdParty/swaylib", tag = "v2.0.0" } |
| 141 | +``` |
| 142 | + |
| 143 | +Run `forc build` to make sure that the project still compiles. **At this point, it is very likely that you will need to compile the project with the experimental features turned on.** The reason is the likelihood that either the new `std` or the `third_party_lib` uses the new Sway features. |
| 144 | + |
| 145 | +To compile the project with experimental features, you can take the feature flags from the `forc migrate show` output, and place them either in the `[build-profile]` section of the projects `Forc.toml` file, or pass them to `forc build` via the command line. |
| 146 | + |
| 147 | +```text |
| 148 | +Experimental feature flags: |
| 149 | +- for Forc.toml: experimental = { storage_domains = true, references = true } |
| 150 | +- for CLI: --experimental storage_domains,references |
| 151 | +``` |
| 152 | + |
| 153 | +In the remaining part of this tutorial, we will be passing the feature flags via the command line. E.g.: |
| 154 | + |
| 155 | +```text |
| 156 | +forc build --experimental storage_domains,references |
| 157 | +``` |
| 158 | + |
| 159 | +### Run the migrations |
| 160 | + |
| 161 | +Once the `my_project` successfully builds with updated dependencies, we can `run` the migration steps on it. E.g.: |
| 162 | + |
| 163 | +```text |
| 164 | +forc migrate run --experimental storage_domains,references |
| 165 | +``` |
| 166 | + |
| 167 | +The `run` command will execute the migration steps, and guide you through the migration process. For each migration step, the output of the step can be one of the following: |
| 168 | + |
| 169 | +| Step output | Meaning | |
| 170 | +| ----------- | ------- | |
| 171 | +| Checked | The step is executed and does not require any changes in code. No action needed. | |
| 172 | +| Review | The step suggests a manual code review. | |
| 173 | +| Changing | The step is automatically changing the code. There might be additional manual actions needed. | |
| 174 | + |
| 175 | +At the end of the `run`, the migration will either guide you to: |
| 176 | + |
| 177 | +- `Continue` the migration process by performing the manual actions and re-running the `forc migrate run` afterwards, |
| 178 | +- or will mark the migration process as `Finished`. At this point, your project will be compatible with the next breaking change version of Sway. |
| 179 | + |
| 180 | +## Migrating workspaces |
| 181 | + |
| 182 | +To migrate a workspace, you will need to migrate each workspace member separately, following the above procedure. The projects should be migrated in order of their dependencies. |
| 183 | + |
| 184 | +## Additional after-migration steps |
| 185 | + |
| 186 | +There are some additional manual steps that might be needed after the migration. |
| 187 | + |
| 188 | +E.g., if tests use hardcoded contract IDs, those need to be changed, because the new version of Sway will, very likely, produce different bytecode. |
0 commit comments