Can you add canister specific build methods in one dfx json?

Developers
1

Hi, I have a project with multiple different canisters working together and would like to organize my repo so I can deploy from root level with one dfx.json and canister_ids.json. Each canister has different mops.toml files and I want to avoid installing unnecessary packages into all the canisters when running mops sources. Is there a way to define specific canister build methods in dfx.json? Or alternatively is there a way to specify which packages should be used for each canister in mops.toml?

1 Like
2

You can add a build property under each canister. For example, if you have a canister named user_backend, then you can have:

"canisters": {
    "user_backend": {
      ...
      "build": "your build command",
      ....
    }
  }

The value in the build key is the command that is executed to produce this canister’s WASM module.

You can use the command dfx schema to get all the property definitions of all of the properties that you can use in dfx.json.

Does this help?

3

I want to build using mops sources however if I use the build command like so:

"canisters": {
    "user_backend1": {
            "main": "backend/apps/user_backend1/src/main.mo",
            "build": "cd backend/apps/user_backend1 && mops sources",
            "type": "motoko"
    },
    "user_backend2": {
            "main": "backend/apps/user_backend1/src/main.mo",
            "build": "cd backend/app",
            "type": "motoko"
    }
  }

I see the error because the packages to be installed are not found in the mops.toml at the canister directory level. If I combine all the packages into one mops.toml file at root level then it works but as said above this does not seem optimal…

4

I can take a closer look tomorrow. @ZenVoich Do you know the workaround?

5

Thank you for the clarification here.

It looks like dfx.json does not support canister-specific packtool commands. @rvanasa looks like we have another request related to this topic!

1 Like
6

Noted! We’ll see what we can do.

7

FWIW, eventhough having one large mops.toml isn’t ideal, I don’t think passing unused packages to the motoko canisters will hurt them in any way.
If no library is imported from a package, there should be no cost (say in binary size) of including it.

3 Likes