why use dependsOn and sync rather than pnpm?

[tomdavidson]

What is the advantage of using moon's dependsOn configuration and sync command rather than pnpm?

[milesj]

@tomdavidson moon supports both explicit (dependsOn) and implicit dependencies (package.json dependency scanning), so you're welcome to use whichever approach you like best. Or you can use them together.

However, explicit is required when you are depending on other projects that are not JavaScript. For example, your frontend application can depend on a backend application that is written in Ruby or something.

In the end, it's all about choice. Use whichever you like best.

https://moonrepo.dev/docs/faq#what-should-be-considered-the-source-of-truth

[milesj]

@tomdavidson It does depending on your Node.js version: https://github.com/moonrepo/moon/blob/master/crates/platform-node/src/actions/install_deps.rs#L19

[tomdavidson]

Thanks. I may have come across a bug but perhaps its worth being quite explicit on the intended behavior here before opening an issue.

moon 0.16.1
NodeJS 18.10.0 (node.version = engines.node)
pnpm 7.13.x

When updating pnpm from 7.13.2 I updated the workspace.yml's node.pnpm.version to to 7.13.5 and then ran moon sync and inspected the root package.json and observed no change.

[milesj]

@tomdavidson Right now moon sync only syncs projects. The packageManager update happens as part of node module installation, which currently does not happen during the sync.

[tomdavidson]

Ok, it did update with setup. I think something like sync that could be fun on a pre-push hook would help keep everything in aligned but ill get some more hands-on before making feature requests. Thanks for helping me adopt moon (Ive been taking newbie experience notes too and will share whats worth sharing).

[milesj]

Definitely, would love to hear them!

[airtonix]

moon supports both explicit (dependsOn) and implicit dependencies (package.json dependency scanning),

@milesj Apologies for digging this up again, but we're struggling to uncover some clear information about how deep this implicit dependency scanning affects the various behaviour throughout moon.

What we want:

# apps/signupsite/moon.yml

tasks:
  foo:
    command: echo "done"
    deps:
      - "^:foo"

then when we run moon run signupsite:foo that any other moon project which is also a listed dependency in apps/signupsite/package.json will have it's foo task run first.

In reality, this isn't happening.

What we looked for and found:

• https://moonrepo.dev/docs/#supported-languages

  • typescript is a tier 3 language, so it should know about deps in package.json

• https://moonrepo.dev/docs/how-it-works/action-graph#what-is-the-graph-used-for

• I notice that moon toolchain info typescript doesn't reveal a extend_action_graph.
  Is this the missing thing for our assumption that we'd be able to assume that task scope of ^ would target deps implied by a projects package.json ?

• Have we misunderstood what you mean by implicit deps?

output from moon toolchain info javascript

Tier 1 - Usage detection ─────────────────────────────────────────

  Config files: tsconfig.json, tsconfig.*.json, *.tsconfig.json, .tsbuildinfo, *.tsbuildinfo

  🟢 define_docker_metadata
  🟢 define_toolchain_config
  ⚫️ detect_version_files
  ⚫️ extend_command
  🟢 initialize_toolchain
  ⚫️ parse_version_file
  ⚫️ prune_docker
  🟢 register_toolchain (required)
  ⚫️ scaffold_docker
  🟢 sync_project
  ⚫️ sync_workspace

Tier 2 - Ecosystem integration ───────────────────────────────────

  ⚫️ define_requirements
  ⚫️ extend_project_graph
  ⚫️ extend_task_command
  ⚫️ extend_task_script
  ⚫️ hash_task_contents
  ⚫️ install_dependencies
  ⚫️ locate_dependencies_root
  ⚫️ parse_lock
  ⚫️ parse_manifest
  ⚫️ setup_environment

Tier 3 - Tool management ─────────────────────────────────────────

  ⚫️ download_prebuilt (required)
  ⚫️ load_versions
  ⚫️ locate_executables (required)
  ⚫️ register_tool (required)
  ⚫️ resolve_version
  ⚫️ setup_toolchain
  ⚫️ teardown_toolchain
  ⚫️ unpack_archive

and that the same for javascript

Tier 1 - Usage detection ─────────────────────────────────────────

  Config files: *.config.{js,cjs,mjs,ts,tsx,cts,mts}, bunfig.toml, deno.json, deno.jsonc, .npmrc, pnpm-workspace.yaml, .pnpmfile.*, .yarn/**/*, .yarnrc.*
  Executable names: bun, bunx, deno, node, nodejs, npm, npx, pnpm, pnpx, yarn, yarnpkg

  ⚫️ define_docker_metadata
  🟢 define_toolchain_config
  ⚫️ detect_version_files
  ⚫️ extend_command
  🟢 initialize_toolchain
  ⚫️ parse_version_file
  ⚫️ prune_docker
  🟢 register_toolchain (required)
  ⚫️ scaffold_docker
  🟢 sync_project
  ⚫️ sync_workspace

Tier 2 - Ecosystem integration ───────────────────────────────────

  Manifest files: package.json
  Lock files: bun.lock, bun.lockb, deno.lock, package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, yarn.lock
  Vendor directory: node_modules

  🟢 define_requirements
  🟢 extend_project_graph
  🟢 extend_task_command
  🟢 extend_task_script
  ⚫️ hash_task_contents
  🟢 install_dependencies
  🟢 locate_dependencies_root
  🟢 parse_lock
  🟢 parse_manifest
  🟢 setup_environment

Tier 3 - Tool management ─────────────────────────────────────────

  ⚫️ download_prebuilt (required)
  ⚫️ load_versions
  ⚫️ locate_executables (required)
  ⚫️ register_tool (required)
  ⚫️ resolve_version
  ⚫️ setup_toolchain
  ⚫️ teardown_toolchain
  ⚫️ unpack_archive

[milesj]

Only javascript does project extending, not typescript. Ensure your project belongs to the javascript toolchain.