[bug] Moon attempts to install dependencies twice in some cases

[eplightning]

Describe the bug

With mono repo that contains following structure (simplified version at https://github.com/eplightning/moon-bugs/tree/install-dep-dup):

- rust/
  - crates/crate1/
    - Cargo.toml
    - moon.yml
  - moon.yml
  - Cargo.toml
  - Cargo.lock 
- js/
  - packages/
    - package1/
      - package.json
      - moon.yml
  - package.json
  - bun.lock
  - moon.yml

Moon tries to install dependencies twice for js projects, concurrently - which will typically package managers, as they don't do any locking usually.

The issue seems to be caused by this line of code:

moon/crates/action-graph/src/action_graph_builder.rs

Line 386 in 404a444

if !in_workspace || in_project && !is_root_level_source(&project.source) {

It assumes that source root of the Bun/cargo/any-other-language workspace must be equal to moon workspace root, which seems extremely limiting. Separating different languages into different directories seems to be pretty common from my experience.

I changed the condition to !in_workspace to confirm if that's the cause - it worked (but probably has some other consequences I'm not aware of).

Steps to reproduce

1. Have repository structure similar to https://github.com/eplightning/moon-bugs/tree/install-dep-dup
2. Run fresh (without .moon/cache) moon run :run
3. There's a race condition and Bun will usually fail because it cannot handle multiple bun install running concurrently

Expected behavior

Each bun workspace runs bun install only once

Error log

  bun install v1.3.3 (274e01c7)
bun install v1.3.3 (274e01c7)
error: Failed to link pino: EEXIST

Checked 27 installs across 28 packages (no changes) [1.00ms]
▪▪▪▪ bun install
▪▪▪▪ bun install --frozen-lockfile
▪▪▪▪ js/package1:run (30063a96)
js/package1:run | test
▪▪▪▪ js/package1:run (20ms, 30063a96)
Error: process::failed

  × Process bun failed: exit code 1

verbose.log

Environment

 System:
    OS: Linux 6.18 Arch Linux
    CPU: (16) x64 AMD Ryzen 7 9800X3D 8-Core Processor
    Memory: 52.51 GB / 62.38 GB
    Container: Yes
    Shell: 5.9 - /usr/bin/zsh
  Binaries:
    Node: 25.2.1 - /usr/bin/node
    npm: 11.6.4 - /usr/bin/npm
    bun: 1.3.3 - /home/eplightning/.proto/shims/bun
    Deno: 2.5.6 - /usr/bin/deno
  Managers:
    Cargo: 1.91.1 - /usr/bin/cargo
    pip3: 25.3 - /usr/bin/pip3
  Utilities:
    7z: 25.01 - /usr/bin/7z
    CMake: 4.2.1 - /usr/bin/cmake
    Make: 4.4.1 - /usr/bin/make
    GCC: 15.2.1 - /usr/bin/gcc
    Git: 2.52.0 - /usr/bin/git
    Clang: 21.1.6 - /usr/bin/clang
    Ninja: 1.13.2 - /usr/bin/ninja
    FFmpeg: 8.0.1 - /usr/bin/ffmpeg
    Curl: 8.17.0 - /usr/bin/curl
    OpenSSL: 3.6.0 - /usr/bin/openssl
  Virtualization:
    Docker: 5.7.0 - /usr/bin/docker
  IDEs:
    Vim: 0.11.5 - /usr/local/bin/vim
  Languages:
    Bash: 5.3.8 - /usr/bin/bash
    Go: 1.25.5 - /usr/bin/go
    Java: 25.0.1 - /usr/bin/javac
    Perl: 5.42.0 - /usr/bin/perl
    Protoc: 33.1 - /usr/bin/protoc
    Python: 3.13.7 - /usr/bin/python
    Python3: 3.13.7 - /usr/bin/python3
    Rust: 1.91.1 - /usr/bin/rustc
    Zig: 0.15.2 - /usr/bin/zig
  Databases:
    SQLite: 3.51.1 - /usr/bin/sqlite3
  Browsers:
    Chromium: 143.0.7499.40
    Firefox: 145.0.2
    Firefox Developer Edition: 145.0.2

Additional context

[milesj]

@eplightning What's the action graph look like?

It's also weird that 1 install has --frozen-lockfile and the other does not.

[eplightning]

Hashes from both install_dependencies jobs:

~/Projects/bun-test> cat /home/eplightning/Projects/bun-test/.moon/cache/hashes/8f1bc5eda5947443b67bb2aea52b9e57dc057d7f4d40d3f9eb3946cde9f4081f.json | jq
[
  {
    "actionNode": {
      "members": [
        "packages/*"
      ],
      "projectId": "js",
      "root": "js",
      "toolchainId": "unstable_javascript"
    },
    "lockfileHash": "2d77675eb3e1ccfc368b36b1dffe73102d929c5b",
    "manifestDependencies": {},
    "manifestPaths": [],
    "project": {
      "alias": "my-project",
      "id": "js",
      "source": "js",
      "toolchains": [
        "unstable_bun",
        "unstable_javascript"
      ]
    },
    "toolchainConfig": {
      "dedupeOnLockfileChange": false,
      "packageManager": "bun"
    },
    "vendorDirExists": true
  }
]
~/Projects/bun-test> cat cat /home/eplightning/Projects/bun-test/.moon/cache/hashes/d92a544e3f5f85b7c886da6bfb196073f405271a0b6efd478ab0856f58976f10.json | jq
cat: cat: No such file or directory
[
  {
    "actionNode": {
      "members": [
        "packages/*"
      ],
      "root": "js",
      "toolchainId": "unstable_javascript"
    },
    "lockfileHash": "2d77675eb3e1ccfc368b36b1dffe73102d929c5b",
    "manifestDependencies": {},
    "manifestPaths": [],
    "project": null,
    "toolchainConfig": {
      "dedupeOnLockfileChange": false,
      "packageManager": "bun"
    },
    "vendorDirExists": true
  }
]

[milesj]

Ok I think I know what is going on.

You have a package.json in the js folder, so in moon's eyes, this is a JS project. But since the workspaces (https://github.com/eplightning/moon-bugs/blob/install-dep-dup/js/package.json#L4) does not include the root (.), it is considered "not in the workspace", so is treated as a separate JS workspace in moon. But...

What's weird though is that the root package should always be considered part of the JS workspace: https://github.com/moonrepo/moon/blob/master/crates/toolchain-plugin/src/toolchain_plugin.rs#L96

[eplightning]

Yes its most likely due to this condition:

moon/crates/action-graph/src/action_graph_builder.rs

Line 386 in 404a444

if !in_workspace || in_project && !is_root_level_source(&project.source) {

in_workspace = true, in_project = true (because root of the workspace == root of the project) and then is_root_level_source is false because its not moon root

[eplightning]

Moving all the workspace level tasks to a fake/empty package inside the workspace (e.g. from js -> js/packages/workspace-hack) works.

Its not ideal because all the tasks need to have their paths adjusted in inputs/outputs/command (use moon workspace relative paths instead of project relative paths), but I guess its a viable workaround for now.