feat: deno init --empty

[GroophyLifefor]

Hi dear Deno Team,

First of all, it's not connected to a issue, I'm a web developer that use Deno for years. All each project, each deno init, I firstly delete main_test.ts, after remove @std/assert imports in deno.json. Today, actually few minutes ago I said to myself Is there no command that does an empty init? I couldn't find one. So yeah, here, deno init --empty command to a real empty project initialize.

I can not tested cargo test because I can not fixed that error

   Compiling unicode-xid v0.2.6
error: failed to run custom build command for `libsqlite3-sys v0.35.0`

Caused by:
  process didn't exit successfully: `C:\Users\***\Desktop\Desktop\Code\***\deno\target\debug\build\libsqlite3-sys-ff8d411b39180a77\build-script-build` (exit code: 101)
  --- stdout
  cargo:rerun-if-env-changed=LIBSQLITE3_SYS_USE_PKG_CONFIG
  cargo:rerun-if-env-changed=LIBSQLITE3_SYS_BUNDLING

[CLAassistant]

All committers have signed the CLA.

[coderabbitai]

Walkthrough

Adds a new --empty flag to deno init and a public pub empty: bool field on InitFlags. When set, init generates a minimal project: main.ts with console.log('Hello world!'); and a deno.json with a dev task. The flag conflicts with --lib, --serve, and --npm. Command parsing and control flow were updated to prioritize the empty path, and integration tests were added/updated to verify the behavior.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 57.14% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description explains the motivation and purpose of the feature—eliminating the manual cleanup steps after deno init by providing an --empty option for minimal project initialization.
Title check	✅ Passed	The title clearly and accurately summarizes the main feature: introducing a new --empty flag for the deno init command that creates a minimal Deno project.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

cli/args/flags.rs (1)

283-292: InitFlags: new empty field will break existing struct initializers (tests) unless updated

Adding pub empty: bool here is fine, but every explicit InitFlags { ... } literal now must include empty or use struct update syntax. The tests in this module still construct InitFlags without empty, which will fail to compile (missing field 'empty'). Please update those initializers (for example in the init tests near the bottom of this file) to set empty: false explicitly.

🧹 Nitpick comments (3)

cli/tools/init/mod.rs (1)

52-69: Empty init branch behavior looks correct; optional DRY-up with default path

The empty-mode path creates the expected minimal scaffold (main.ts with “Hello world!” and a deno.json with only a dev task) and reuses the existing file helpers, so behavior and error handling are consistent with other modes. The only minor nit is that the "deno run --watch main.ts" task definition is now duplicated with the default path; if you expect that to evolve over time, consider extracting the common JSON snippet into a small helper to avoid drift, but this is non-blocking.

tests/integration/init_tests.rs (1)

174-211: Strengthen --empty test to assert deno.json has no std/assert or test config

The test does a good job covering the new empty mode (no cd, no deno test in guidance, only main.ts, correct output). Given the PR’s motivation—avoiding @std/assert and test scaffolding—it would be useful to assert that deno.json reflects that as well.

For example, after checking that deno.json exists, you could also verify it doesn’t reference @std/assert (or other test-related scaffolding):

-  assert!(cwd.join("deno.json").exists());
+  let deno_json_path = cwd.join("deno.json");
+  assert!(deno_json_path.exists());
+
+  let deno_json_content = deno_json_path.read_to_string();
+  assert!(!deno_json_content.contains("@std/assert"));

This makes the test guard precisely against the regression the flag is meant to prevent.

cli/args/flags.rs (1)

3162-3168: --empty flag wiring looks consistent, but it probably should conflict with --npm

The new empty flag is correctly threaded:

• Defined on the init subcommand and mapped into InitFlags.empty via matches.get_flag("empty") and inner_matches.get_flag("empty").
• Propagated into DenoSubcommand::Init(InitFlags { ..., empty, .. }).

One concern: Arg::new("empty") only conflicts with lib and serve, and Arg::new("npm") only conflicts with lib and serve. That means deno init --npm <pkg> --empty is currently accepted and produces InitFlags { package: Some(...), empty: true, ... }, even though empty is only meaningful for the non‑npm scaffold path.

Consider tightening the CLI contract so --empty and --npm are mutually exclusive, for example by adding empty to the npm arg’s conflicts_with_all list or adding "npm" to the empty arg’s conflicts_with_all.

Also applies to: 5946-5981

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c27d8f0 and 4cb439a.

📒 Files selected for processing (3)

• cli/args/flags.rs (5 hunks)
• cli/tools/init/mod.rs (2 hunks)
• tests/integration/init_tests.rs (1 hunks)

🧰 Additional context used

📓 Path-based instructions (3)

cli/tools/**/*.rs

📄 CodeRabbit inference engine (CLAUDE.md)

CLI tools should be implemented in cli/tools/<tool> or cli/tools/<tool>/mod.rs

Files:

• cli/tools/init/mod.rs

**/*.rs

📄 CodeRabbit inference engine (CLAUDE.md)

**/*.rs: For debugging Rust code, set breakpoints in IDE debuggers (VS Code with rust-analyzer, IntelliJ IDEA) or use lldb directly
Use eprintln!() or dbg!() macros for debug prints in Rust code

Files:

• cli/tools/init/mod.rs
• cli/args/flags.rs
• tests/integration/init_tests.rs

---

⚙️ CodeRabbit configuration file

Don't worry about coverage of Rust docstrings. Don't be nitpicky about it. Leave it to the author's judgement if such a documentation is necessary.

Files:

• cli/tools/init/mod.rs
• cli/args/flags.rs
• tests/integration/init_tests.rs

cli/args/flags.rs

📄 CodeRabbit inference engine (CLAUDE.md)

CLI flag parsing should be defined in cli/args/flags.rs

Files:

• cli/args/flags.rs

🧠 Learnings (1)

📚 Learning: 2025-11-24T16:19:37.808Z

Learnt from: CR
Repo: denoland/deno PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-24T16:19:37.808Z
Learning: Applies to cli/args/flags.rs : CLI flag parsing should be defined in `cli/args/flags.rs`

Applied to files:

• cli/args/flags.rs

🧬 Code graph analysis (2)

cli/tools/init/mod.rs (1)

cli/util/fs.rs (1)

• create_file (22-50)

tests/integration/init_tests.rs (1)

tests/util/server/src/builders.rs (1)

• for_jsr (114-116)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (10)

• GitHub Check: test debug linux-x86_64
• GitHub Check: test debug macos-aarch64
• GitHub Check: test debug linux-aarch64
• GitHub Check: test debug windows-x86_64
• GitHub Check: test release linux-x86_64
• GitHub Check: test debug macos-x86_64
• GitHub Check: build libs
• GitHub Check: lint debug windows-x86_64
• GitHub Check: lint debug macos-x86_64
• GitHub Check: lint debug linux-x86_64

🔇 Additional comments (1)

cli/tools/init/mod.rs (1)

247-256: Init guidance for --empty is consistent and avoids test hints

The new logging branch for init_flags.empty matches the scaffold you create: it only mentions running main.ts and the dev task, and correctly omits any deno test hints since no tests are generated. This keeps the UX aligned with the “empty” intent.

[bartlomieju]

Please sign the CLA so we could land this PR

[GroophyLifefor]

Please sign the CLA so we could land this PR

I did right now.

[bartlomieju]

Thanks