sui move build fails to compile when [dev-dependencies] is used

[avernikoz]

Steps to Reproduce Issue

The issue can be reproduced by attempting a standard build on a package where the [dev-dependencies] section is populated.
The compiler fails to build the project, citing issues with named addresses and unbound modules, even though the configuration is valid for a standard build.
The provided repository is already configured in the failing state.

1. Clone the reproduction repository:

    git clone https://github.com/avernikoz/sui-dev-deps-override-repro.git
    cd sui-dev-deps-override-repro

2. Run the build command from within the main_package directory:

    cd main_package
    sui move build

To verify that the project is otherwise configured correctly, you can comment out the [dev-dependencies] section in main_package/Move.toml and run sui move build again; the build will then succeed.

Expected Result

The build command should succeed.
According to the official documentation (The Move Book and the Sui Developer Guide), the [dev-dependencies] and [dev-addresses] sections should only be included in "dev" and "test" modes (i.e., when the --dev or --test flags are used).
For a standard sui move build, the compiler should completely ignore these sections and resolve dependencies and named addresses using only the main [dependencies] and [addresses] sections.

This separation is critical for a secure and robust development lifecycle. The [dependencies] section is intended to define the exact, stable, and often audited dependencies that will be included in the final on-chain package. The [dev-dependencies] section, in contrast, is designed to allow developers to use local or remote forks for development and testing purposes.

The primary motivation for this is to facilitate comprehensive unit testing. For example, a developer might need to add #[test_only] functions to a dependency to properly test their own package's interactions with it. This requires using a modified, local version of that dependency. The [dev-dependencies] feature seems to be correct mechanism to enable this workflow, ensuring that the development-only forks and #[test_only] additions are completely excluded from the final production build.

Without this feature working as documented, developers are forced into error-prone workarounds, hindering their ability to write thorough tests or compromising the integrity of the production package configuration.

Actual Result

The build fails with multiple compilation errors:

error[E03001]: address with no value
  ┌─ ./sources/main_package.move:6:5
  │
6 │ use deepbook::pool::Pool;
  │     ^^^^^^^^ address 'deepbook' is not assigned a value

error[E03002]: unbound module
  ┌─ ./sources/main_package.move:6:5
  │
6 │ use deepbook::pool::Pool;
  │     ^^^^^^^^^^^^^^ Invalid 'use'. Unbound module: 'deepbook::pool'

error[E03001]: address with no value
  ┌─ ./sources/main_package.move:7:5
  │
7 │ use pyth::price_info::PriceInfoObject;
  │     ^^^^ address 'pyth' is not assigned a value

error[E03002]: unbound module
  ┌─ ./sources/main_package.move:7:5
  │
7 │ use pyth::price_info::PriceInfoObject;
  │     ^^^^^^^^^^^^^^^^ Invalid 'use'. Unbound module: 'pyth::price_info'

Failed to build Move modules: Compilation error

System Information

• OS: macOS (Darwin 23.6.0)
• Compiler: sui 1.52.3-cd58464d654d

[github-actions]

Thank you for opening this issue, a team member will review it shortly. Until then, please do not interact with any users that claim to be from Sui support and do not click on any links!

[gfusee]

I checked the code, and I have a feeling that the following line causes the issue:
dep_graphs.extend(dev_dep_graphs); in DependencyGraphBuilder::get_graph.

If dep_graphs and dev_dep_graphs have duplicate keys (this is the case here with Pyth and deepbook), the ones from dev_dep_graphs are used.
The issue is that in dev_dep_graphs, all the values have the field mode set to DependencyMode::DevOnly.

Since you're not building using --dev or --test, the function DependencyGraph::immediate_dependencies filters out all dependencies with DependencyMode::DevOnly.

So, in your example, Pyth and Deepbook are discarded, while they shouldn't be.

I might be wrong tho, this is only a deduction I had by reading the sui code.

[stefan-mysten]

Thanks @avernikoz for flagging this. I was able to reproduce but did not have a chance to look more into why this is happening. It might be what @gfusee is describing, I'll have a closer look asap.

[hoangquocvietuet]

Currently, during package resolution the code prioritizes dev packages. In dev mode, it returns all packages; otherwise, it filters out the dev packages.

My question is: why do we need to include both dev and always packages in the resolution step? Wouldn’t it be simpler to only include the packages relevant to the current compilation mode (i.e., include all in dev mode, or only non-dev in normal mode)?

cc @stefan-mysten

[stefan-mysten]

@gfusee I think you are right. The merging logic incorrectly prioritizes the dev version, causing it to be marked as DevOnly and subsequently filtered out in non-dev builds.

why do we need to include both dev and always packages in the resolution step

I am not 100% sure, but it might be needed for ensuring that we can have a consistent lock file across build modes.

[stefan-mysten]

I pushed a PR to fix this, let's see if it passes all the existing tests.

[hoangquocvietuet]

Prioritizing always packages won’t solve the problem, because when we run sui move build --dev, the build doesn’t actually use the dev packages that we need.

[gfusee]

I also created a PR today: #23271. I included all the details in the description. @stefan-mysten's one is simpler, but if it doesn't pass the tests or doesn't fix the issue maybe mine could help 🙏