@niroai/niro 0.16.0 → 0.17.0

package/CHANGELOG.md

@@ -4,6 +4,19 @@ Notable changes to `@niroai/niro`. Dates are release dates.
 
 ## Unreleased
 
+## 0.17.0 — 2026-09-23
+
+### `niro init --defaults` still asks which project
+
+`--defaults` accepts default values: env vars, indexing scope, the project name. It also used to
+skip the "new project, or add to an existing one?" question and always create a new project, which
+put repos in the wrong place for anyone who already had a project for them. Which project is not a
+default value, so in a terminal the question is now asked with `--defaults` too.
+
+Unattended runs are unchanged. With no terminal (CI, a piped script, an agent's shell) there is no
+question and a new project is created, as before. A script that wants an existing project passes
+`--add-to <alias|id>`; `--project-name <name>` still skips the question everywhere.
+
 ## 0.16.0 — 2026-09-22
 
 ### A reverse proxy's routing table is offered for upload

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@niroai/niro",
-  "version": "0.16.0",
+  "version": "0.17.0",
   "description": "Niro \u2014 one package: the niro CLI plus the Niro MCP server (code intelligence for AI coding assistants).",
   "keywords": [
     "niro",

package/src/commands/init.js

@@ -946,10 +946,11 @@ async function scanIndexedChildren(targetDir, opts, resolve = resolveContext) {
  * Decide the TARGET of this onboarding up front, before any repo registration:
  *   - --add-to <alias|id> -> EXISTING: resolve to a real projectId (throws on
  *     ambiguity/not-found via resolveProjectId), attach the new repo to it later.
- *   - --project-name / --defaults / non-interactive -> NEW: derive a free name
- *     exactly as before (unchanged behaviour for scripts and the default path).
+ *   - --project-name / non-interactive -> NEW: derive a free name exactly as
+ *     before (unchanged behaviour for scripts).
  *   - INTERACTIVE with >=1 existing project -> show a numbered menu (new vs each
  *     existing project) so the user can attach instead of always creating new.
+ *     This holds with --defaults too.
  *
  * Returns { projectId, isExisting } or null when the user/flags didn't yield a
  * usable target (caller sets exitCode=1).
@@ -966,10 +967,14 @@ async function resolveTarget({ defaultName, opts }) {
     return { projectId, isExisting: true };
   }
 
-  // Explicit name, --defaults, or a non-interactive shell -> NEW (current path).
+  // Explicit name or a non-interactive shell -> NEW (current path).
   // We only offer the existing-project menu in an interactive shell with at
-  // least one project to pick.
-  if (!opts.projectName && !opts.defaults && !prompt.isNonInteractive()) {
+  // least one project to pick. --defaults does NOT skip it: that flag accepts
+  // default VALUES (env vars, scope, name), and "which project" has no safe
+  // default, so creating a new one silently put repos in the wrong place.
+  // Unattended runs have no terminal, so they still go straight to NEW; a
+  // script that wants an existing project passes --add-to.
+  if (!opts.projectName && !prompt.isNonInteractive()) {
     const existing = await fetchExistingProjects(opts);
     if (existing.length > 0) {
       const chosen = await chooseTarget(existing);