Repository navigation
feat(cli): support schema input via stdin #174
Description
Current task
Support --schema - for native commands that currently require a schema file path.
Start with:
wesley schema lower --schema -wesley schema hash --schema -wesley schema operations --schema -wesley emit rust --schema - --out <path>wesley emit typescript --schema - --out <path>wesley emit le-binary-rust --schema - --out <path>wesley emit le-binary-typescript --schema - --out <path>
Add other schema-consuming commands only if they use the same helper cleanly.
Acceptance criteria
- A shared Rust CLI input helper treats
--schema -as stdin and all other schema values as filesystem paths. - Empty stdin fails with a clear deterministic error.
- File-path behavior remains unchanged.
- Help/reference docs mention
--schema -where applicable. - Integration tests cover at least one schema inspection command and one emitter command using stdin.
Out of scope
- Autodetecting stdin when no
--schemais supplied. - Watch mode or target execution.
- Domain-specific provenance semantics beyond a simple input-origin note if existing metadata has a natural place for it.
Activity
flyingrobots commentedon Oct 22, 2025
Priority: 3/5
Rationale: This is a medium-priority feature. Supporting schema input via stdin significantly enhances the flexibility and automation capabilities of the Wesley CLI. It allows for seamless integration into CI/CD pipelines and scripting workflows where schemas might be generated dynamically or not persisted to disk.
Complexity: 2/5
Rationale: This is a low to medium-complexity task. It involves:
--schema -or implicit detection).This will primarily impact the
wesley-clipackage and its interaction with the GraphQL parser.Estimate: 10-20 hours
Rationale: This estimate includes time for implementing stdin reading logic, integrating it with the existing schema parsing, and writing tests to cover various stdin input scenarios (e.g., empty input, large input). The higher end accounts for ensuring robust error handling and clear provenance messaging in the generated output.
flyingrobots commentedon Oct 22, 2025
Priority: 3/5
Rationale: This is a medium-priority feature. Supporting schema input via stdin significantly enhances the flexibility and automation capabilities of the Wesley CLI. It allows for seamless integration into CI/CD pipelines and scripting workflows where schemas might be generated dynamically or not persisted to disk.
Complexity: 2/5
Rationale: This is a low to medium-complexity task. It involves:
--schema -or implicit detection).This will primarily impact the
wesley-clipackage and its interaction with the GraphQL parser.Estimate: 10-20 hours
Rationale: This estimate includes time for implementing stdin reading logic, integrating it with the existing schema parsing, and writing tests to cover various stdin input scenarios (e.g., empty input, large input). The higher end accounts for ensuring robust error handling and clear provenance messaging in the generated output.
flyingrobots commentedon Jun 25, 2026
Triage decision before state change:
This issue appears to track: schema input through stdin.
Current Wesley doctrine: Wesley core owns GraphQL -> deterministic, extensible IR plus generic tooling and assurance for that contract. Domain-specific targets stay downstream; retained issues are scoped to domain-free compiler/tooling behavior.
Decision: keep in Wesley and schedule for v0.4.0.
Rationale: Reading GraphQL SDL from stdin is domain-free CLI ergonomics for automation.
Next action: remove
triage:cool-ideas, addlane:v0.4.0, and assign the issue toGoalpost: Make It a Real Platform.