Post-build step for asset canister fails because directory is considered to be outside the workspace root

[paulyoung]

My dfx.json looks like this:

{
  "version": 1,
  "dfx": "0.9.2",
  "canisters": {
    "myproject": {
      "type": "custom",
      "build": "nix build",
      "candid": "backend/src/myproject/src/myproject.did",
      "wasm": "result/target/wasm32-unknown-unknown/release/myproject.wasm"
    },
    "myproject_assets": {
      "type": "assets",
      "dependencies": [
        "myproject"
      ],
      "frontend": {
        "entrypoint": "result/dist/index.html"
      },
      "source": [
        "result/dist/"
      ]
    }
  },
  "networks": {
    "local": {
      "bind": "127.0.0.1:8000",
      "type": "ephemeral"
    }
  }
}

There's apparently some issue with using "result/dist/" as the source directory because when I run dfx deploy myproject_assets I see Error: The post-build step failed for canister 'ryjl3-tyaaa-aaaaa-aaaba-cai' with an embedded error: Directory at '/Users/py/projects/paulyoung/myproject/main/result/dist/' is outside the workspace root.

I suspect this is because result is actually a symlink to /nix/store/<hash>-myproject. I'm working around this for now but it might be nice if people could opt out of this check.

Also, is there a way to specify a build command for asset canisters? The above relies on the dependency of myproject to put the assets in the right place. It would help with my workaround if I could decouple the two.

[paulyoung]

My workaround is as follows.

"build": "bash -c \"nix build && rm -rf result-assets && mkdir result-assets && cp -R result/dist result-assets && chmod 775 -R result-assets\"",

I'm using bash -c because otherwise is treated && as a command and I get an error complaining that it doesn't exist.

It would be great if things like foo && bar just worked.

[viviveevee]

Hi Paul, I feel your pain! We have reworking the custom build command on our backlog and know the current state is mediocre at best. Thanks for giving good examples that we can test against!

[paulyoung]

I think I saw some code that looked like it might try to write to the provided directory as well. If that's true then that would have been another problem I would have run into.

[paulyoung]

@sesi200 I saw some PRs mentioning this so I wondered if I had missed anything that might allow me to work around this now.

[paulyoung]

I think it would help if "build" was allowed when "type": "asset".

I'm surprised that doesn't work; the assets need to get built somehow, and having something like "build": "npm run build" seems very reasonable.

[krpeacock]

It currently runs npm run build for asset canisters, but there's no reason we can't make that customizable