Context: This affects framework development only (the monorepo workspace), not end users who scaffold via kit new myapp && cd myapp && kit serve
When developing the framework and running the example app via ./dev.sh (or cargo run -p app from the workspace root), the app panics:
thread 'main' panicked at framework/src/app.rs:297:53:
DATABASE_URL must be set: NotPresent
Root cause: Config::init(Path::new(".")) in framework/src/app.rs:218 loads .env relative to CWD.
dev.sh runs cargo run -p app from the workspace root (kit/), but .env lives in kit/app/.
So dotenvy never finds it.
Current workaround: cd app before running, or wrap in a subshell: (cd app && cargo run -p app)
Suggested fix: Config::init could resolve the project root using CARGO_MANIFEST_DIR or similar, rather than assuming CWD == project root. This would make it robust for both end users and workspace development.
Affected files:
framework/src/app.rs:218 — Config::init(Path::new("."))framework/src/config/env.rs:71 — load_dotenv(project_root) receives . as-is
I'm happy to submit a PR :)
Context: This affects framework development only (the monorepo workspace), not end users who scaffold via
kit new myapp && cd myapp && kit serveWhen developing the framework and running the example app via
./dev.sh(orcargo run -p appfrom the workspace root), the app panics:Root cause:
Config::init(Path::new("."))inframework/src/app.rs:218loads.envrelative to CWD.dev.shrunscargo run -p appfrom the workspace root (kit/), but.envlives inkit/app/.So
dotenvynever finds it.Current workaround:
cd appbefore running, or wrap in a subshell:(cd app && cargo run -p app)Suggested fix:
Config::initcould resolve the project root usingCARGO_MANIFEST_DIRor similar, rather than assuming CWD == project root. This would make it robust for both end users and workspace development.Affected files:
framework/src/app.rs:218 — Config::init(Path::new("."))framework/src/config/env.rs:71—load_dotenv(project_root)receives . as-isI'm happy to submit a PR :)