dx: add --verbose/--debug CLI flags and config validation command
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- typescript
- Domain
- build-system, cli, developer-experience
Research direction
Start at src/cli/index.ts and trace the config loader, build flow, and dev-server entry points; inspect package.json for the version source. Define completion against each requested behavior: diagnostic flags, chronicle validate checks, package-derived version, port-conflict handling, and bundle-size reporting.
Written by the indexing model from the issue text.
Description
Problem
Several developer experience gaps in the CLI:
- No `--verbose`/`--debug` flags — when builds fail or config is wrong, there's no way to get detailed output. Config parse errors are silently swallowed by `loadConfig()`.
- No `chronicle validate` command — no way to check config validity without starting the server. Useful in CI pipelines.
- CLI version hardcoded to `'0.1.0'` in `src/cli/index.ts` — should be read from `package.json`.
- Dev server doesn't check port conflicts — starts without warning if the port is already in use.
- Build doesn't report bundle size — no output size summary or warnings for large bundles.
Suggested Fix
- Add `--verbose` global flag that enables debug logging throughout the config loader, build, and dev server
- Add a `chronicle validate` command that parses config, checks content dirs exist, validates API spec files are readable, and reports issues
- Read version from `package.json` at build time
- Check port availability before starting dev server, suggest next available port
- Dominant language
- TypeScript
- Stars
- 2
- Forks
- 1
- Avg merge
- 13h 36m
- Merged PRs (30d)
- 11
Getting set up
We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from raystack/chronicle
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Maintainers usually reply within 1 day
All issues in raystack/chronicle
Similar issues
-
check:passed streams:add
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Fission-AI/OpenSpec#1986 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
nestjs/docs.nestjs.com#3554 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
publicodes/publicodes#868 ·
-
namespace operations
Difficulty 1/5 Under an hour Newbie friendliness 78/100
EclipseFdn/open-vsx.org#13488 ·
Maintainers usually reply within 2 days