Skip to content

feat: make PHP module discovery cwd-aware - #1

Open
tiborvass wants to merge 1 commit into
mainfrom
codex/cwd-aware-module-discovery
Open

feat: make PHP module discovery cwd-aware#1
tiborvass wants to merge 1 commit into
mainfrom
codex/cwd-aware-module-discovery

Conversation

@tiborvass

Copy link
Copy Markdown

What changed

  • Replace workspace-root dagger.json scanning with cwd-aware config discovery through dagger/polyfill.
  • Support both CLI 1.0 dagger-module.toml and legacy dagger.json, choosing the nearest config regardless of filename ordering.
  • Intersect discovered roots with the PHP SDK modules managed by the explicitly passed workspace via currentModule.asSDK(workspace: ws).
  • Separate stable workspace-root-relative Mod.rootPath from the cwd-relative public Mod.path.
  • Anchor rootPath at / when resolving module sources so generation works from a module root or another nested directory.
  • Exclude Composer vendor trees, update the polyfill dependency, and document the new behavior.
  • Add end-to-end fixtures for mixed config formats, managed/non-PHP filtering, explicit workspace resolution, cwd scoping, and rooted generation.

Why

The previous implementation scanned every legacy dagger.json from the workspace root. That ignored the caller's cwd, could not discover modern TOML modules, and could disagree with the workspace's engine-owned managed-module list.

Keeping root-relative identity separate from cwd-relative display paths also prevents nested generation from interpreting a stable module root relative to the cwd and prefixing that cwd twice.

Validation

Validated against a current locally built Dagger dev engine:

dagger check

All 3 checks pass:

  • e-2-e:module-lookup-check
  • e-2-e:module-discovery-check
  • e-2-e:generate-cwd-check

Related implementations

Discover managed PHP modules from the caller workspace and cwd across both dagger-module.toml and legacy dagger.json configs.

Keep workspace-root module identity separate from cwd-relative display paths, explicitly bind asSDK to the passed workspace, and anchor generation paths at the workspace root.

Add end-to-end coverage for mixed config ordering, scoped discovery, explicit workspace resolution, and generation from nested directories.
@tiborvass
tiborvass marked this pull request as ready for review July 27, 2026 17:15
@TomChv

TomChv commented Jul 28, 2026

Copy link
Copy Markdown
Member

Let's do dagger/typescript-sdk#12 (modulesource.generateLocalDependencies changes) in a follow up PR, this one module looks pretty good already

@TomChv

TomChv commented Jul 28, 2026

Copy link
Copy Markdown
Member

Trying to run dagger generate after initializing a php module throw this error:

loading module "/private/tmp/_manual_dagger_test/_test_php/.dagger/modules/bar": resolving module source "/private/tmp/_manual_dagger_test/_test_php/.dagger/modules/bar": failed to load sdk for local module source: invalid SDK: "github.com/dagger/dagger/sdk/[email protected]"

The fix is to pin engineVersion to v1.0.0-beta.7 instead of latest until we fix that behaviour in the engine?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants