[bartlomieju]

Summary

Builds on the --package-json flag (added in Deno 2.8) by introducing a persistent "preferPackageJson": true setting in deno.json. When enabled, dependency management commands always target package.json:

• deno add / deno install <pkg> / deno remove write to package.json instead of deno.json
• a package.json is created automatically if one doesn't exist
• it's equivalent to passing --package-json to those commands on every invocation

It also prints a warning when imports/scopes are still present in deno.json while preferPackageJson is enabled, nudging users to move those dependencies to package.json.

// deno.json
{
  "preferPackageJson": true
}

$ deno add npm:chalk
Created package.json configuration file.
Add npm:chalk@5.x.x

Implementation

• preferPackageJson added to the ConfigFileJson schema and the JSON schema (config-file.v1.json) for editor autocompletion.
• Workspace::prefer_package_json() reads the setting from the root deno.json.
• cli/tools/pm/mod.rs folds the setting into the existing force_package_json path that already powers --package-json, so add/install/remove all honor it. link/unlink explicitly opt out, since the "links" field lives in deno.json.
• The imports warning rides the existing workspace-diagnostics path (new WorkspaceDiagnosticKind::PreferPackageJsonWithImports).

Tests

• tests/specs/add/prefer_package_json — routes deps into package.json; creates it when missing.
• tests/specs/add/prefer_package_json_imports_warning — warning fires when imports is present.

Existing package_json_flag, link, remove, and deno_config tests pass.

[bartlomieju]

I would prefer we don't print this message

[bartlomieju]

Reviewed — solid and well-tested. A few notes:

Confirmed correct:

• deno install <pkg> is genuinely covered even though the diff only touches add/remove: installer/local.rs routes InstallFlagsLocal::Add → pm::add(.., AddCommandName::Install), which now passes honor_prefer_package_json = true. Bare deno install (TopLevel) bypasses add() and is correctly unaffected.
• link/unlink opt-out is correct (the "links" field stays in deno.json).
• In the force path load_configs always returns npm_config = Some(..), so the .unwrap() calls in add/remove can't panic.
• has_dependency_imports uses value_to_dep_req, which matches only npm:/jsr: specifiers, so path-alias imports ("#utils": "./utils.ts") correctly don't warn. Nicely covered by the unit tests.

One design point on the new PreferPackageJsonWithImports warning: it rides workspace.diagnostics(), which is drained in CliOptions::from_flags (cli/args/mod.rs) for essentially every command that loads the workspace — deno run, deno test, deno check, etc., not just add/install/remove. That's a more aggressive cadence than its siblings on that path (which are hard misconfigurations vs. this advisory migration nudge). Global emission is a reasonable choice if intended — just flagging it as deliberate. It correctly honors --quiet/--log-level error for free since it's a log::warn! and init_logging runs before the diagnostics are drained.

Minor: the diff adds a third spec (prefer_package_json_remove) the PR description doesn't mention; and under preferPackageJson the importMap-field bail in add() is skipped (deno_config is None), which is arguably fine but a slight asymmetry vs. plain deno add.