resolver: throw ERR_INVALID_PACKAGE_CONFIG for malformed package.json

[robobun]

What

An invalid package.json (malformed JSON, non-object root, or a "type" field that is not a string) was silently ignored by the runtime module loader. Every .js file under it loaded with whatever module format content-sniffing or the nearest valid ancestor produced, with no error and no warning.

Node.js refuses the whole package scope with ERR_INVALID_PACKAGE_CONFIG on every load path (static import, import(), require(), entrypoint). A corrupted, half-written, or merge-conflicted package.json must not silently change the module semantics of every file beneath it.

Repro

// repro.mjs
import { mkdtempSync, writeFileSync, mkdirSync } from "node:fs";
import { spawnSync } from "node:child_process";
const d = mkdtempSync("/tmp/badpkg-");
mkdirSync(`${d}/pkg`);
writeFileSync(`${d}/package.json`, '{"name":"root"}');
writeFileSync(`${d}/pkg/package.json`, "{\n");           // malformed
writeFileSync(`${d}/pkg/t.js`, 'export const x = 7;\nconsole.log("ran");\n');
writeFileSync(`${d}/p.mjs`, 'import * as N from "./pkg/t.js"; console.log("ns", Object.keys(N));');
for (const rt of ["node", process.execPath]) {
  const r = f => { const p = spawnSync(rt, [f], { cwd: d, encoding: "utf8" });
    return p.status === 0 ? p.stdout.trim().split("\n").pop() : (p.stderr.match(/ERR_INVALID_PACKAGE_CONFIG/)?.[0] ?? "exit " + p.status); };
  console.log(rt.split("/").pop().padEnd(8), "| import:", r("./p.mjs").padEnd(30), "| entrypoint:", r("./pkg/t.js"));
}

Before:

node     | import: ERR_INVALID_PACKAGE_CONFIG     | entrypoint: ERR_INVALID_PACKAGE_CONFIG
bun      | import: ns [ "x" ]                     | entrypoint: ran

After:

node     | import: ERR_INVALID_PACKAGE_CONFIG     | entrypoint: ERR_INVALID_PACKAGE_CONFIG
bun      | import: ERR_INVALID_PACKAGE_CONFIG     | entrypoint: ERR_INVALID_PACKAGE_CONFIG

Same divergence held for {"type":42} (schema-invalid), 42 (non-object root), across all four load paths.

Cause

Three layers swallowed the failure:

1. JsonCache::parse_rows converts a JSON parse Err into Ok(None), pushing diagnostics into the resolver log only.
2. PackageJSON::parse returned None on Ok(None) / non-object root, and only warned on non-string "type". (A 0-byte file is intentionally left as {} to preserve Bun's existing JSONC-empty convention; see jsonc.test.ts.)
3. Resolver::dir_info_uncached did .ok().flatten() and cached package_json = None, so the parent scope was inherited for module-type resolution.

The process-lifetime DirInfo cache then treated the invalid file exactly like "no package.json here" for the rest of the process.

Fix

• PackageJSON gains an invalid: bool field.
• PackageJSON::parse returns a poisoned entry (invalid = true, path set, everything else default) instead of None on parse failure / non-object root, and marks non-string "type" as invalid.
• DirInfo gains nearest_package_json: the first package.json walking up, regardless of name or validity. This is Node's actual package-scope boundary for "type" resolution, distinct from enclosing_package_json (which skips nameless entries per Support running package.json scripts from package.json without a name #229 for bun run/bin purposes). A valid nameless {} or {"type":...} between a poisoned ancestor and a file correctly terminates the scope.
• The runtime module-type lookups in jsc_hooks.rs use nearest_package_json. transpile_file throws ERR_INVALID_PACKAGE_CONFIG (with the offending path) when it needs the package.json to determine the module format of a .js/.ts file. .mjs/.cjs still load fine since their format comes from the extension, matching Node.
• enclosing_package_json keeps its original assignment condition. A package.json with a non-string "type" but valid scripts still becomes enclosing, so bun run <script> finds it (matches npm/pnpm/yarn). filter_run / multi_run filter out only the unparseable poisoned entries (empty source_contents) so the existing "skipping this workspace package" warning still fires for those while scripts from a fully-parsed entry with a bad "type" continue to run.

Unknown string "type" values ("type":"nonsense") continue to be treated as unset, also matching Node.

One side effect for bun run <script>: when the cwd's own package.json is truly unparseable, bun now stops there ("Script not found") instead of silently falling through to a parent directory's scripts. npm/pnpm/yarn all refuse to fall through in that case (they error on the parse), so this brings bun run in line with them.

Tests

describe.concurrent("ERR_INVALID_PACKAGE_CONFIG") in test/js/bun/resolve/resolve-error.test.ts covers the 3 invalid shapes x 4 load paths, plus negative cases (.mjs/.cjs still load, unknown string "type" does not error, parent scope unaffected, error is catchable with .code, valid nameless intermediate stops poison propagation). 14 of the 22 cases fail on main and pass with this change. Additional regression guards in filter-workspace.test.ts and run_command.test.ts cover the non-string-"type" + scripts case.

---

no test proof · iteration 3 · Platform-specific test(s) that do not run on this machine. Deferring to CI, which covers all platforms: test/cli/run/filter-workspace.test.ts test/cli/run/run_command.test.ts test/js/bun/resolve/resolve-error.test.ts

[coderabbitai]

Walkthrough

Changes

The resolver now preserves invalid package.json files, tracks the nearest package boundary, reports invalid module configurations, and updates CLI package discovery. Tests cover CLI execution, loader errors, extension overrides, and scope-boundary behavior.

Package configuration resolution

Layer / File(s)	Summary
PackageJSON invalid-state parsing src/resolver/package_json.rs	PackageJSON records invalid configurations, including malformed JSON, non-object values, and non-string type fields, while returning poisoned parse results.
Nearest package boundary tracking src/resolver/dir_info.rs, src/resolver/resolver.rs	DirInfo stores the nearest package JSON, and resolver traversal propagates or replaces it at package boundaries.
Runtime module resolution and CLI filtering src/runtime/jsc_hooks.rs, src/runtime/cli/filter_run.rs, src/runtime/cli/multi_run.rs	Runtime module detection uses the nearest package JSON, invalid configurations return ERR_INVALID_PACKAGE_CONFIG, and CLI discovery filters poisoned results.
Invalid configuration regression coverage test/cli/run/filter-workspace.test.ts, test/cli/run/run_command.test.ts, test/js/bun/resolve/resolve-error.test.ts	Tests cover non-string type values, script execution, resolver errors, extension overrides, and package scope boundaries.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly states the main change: throwing ERR_INVALID_PACKAGE_CONFIG for malformed package.json.
Description check	✅ Passed	The description covers the behavior change, rationale, repro, fix, and testing, even though the headings differ from the template.

---

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

[robobun]

^{Updated 1:16 AM PT - Jul 10th, 2026}

❌ @robobun, your commit e3af988 has 2 failures in Build #71382 (All Failures):

• test/js/node/test/sequential/test-net-localport.js - code 1 on 🐧 3.23 x64-baseline
• test/js/node/test/sequential/test-net-localport.js - code 1 on 🐧 3.23 x64
• test/js/node/test/parallel/test-worker-message-port-transfer-terminate.js - SIGABRT on 🐧 13 x64-asan

---

🧪   To try this PR locally:

bunx bun-pr 33890

That installs a local version of the PR into your bun-33890 executable, so you can run:

bun-33890 --bun

[claude]

All prior review feedback has been addressed and I found nothing new, but this touches core resolver/module-loading semantics (new nearest_package_json scope boundary, poisoned PackageJSON entries, an intentional bun run fallthrough change) and uses source_contents.is_empty() as the discriminator between "unparseable" and "invalid-type-only" — worth a human sign-off on the design.

Extended reasoning...

Overview

This PR changes how Bun's resolver and runtime module loader handle malformed package.json files, adding Node-compatible ERR_INVALID_PACKAGE_CONFIG errors. It touches:

• src/resolver/package_json.rs — adds invalid: bool, returns poisoned entries instead of None for malformed JSON / empty file / non-object root / non-string "type"
• src/resolver/dir_info.rs + resolver.rs — adds nearest_package_json (Node's package-scope boundary, distinct from the name-gated enclosing_package_json)
• src/runtime/jsc_hooks.rs — 4 module-type lookup sites switched to nearest_package_json; transpile_file now throws ERR_INVALID_PACKAGE_CONFIG for .js/.ts under a poisoned scope
• src/runtime/cli/{filter_run,multi_run}.rs — filter poisoned entries so the existing "skipping this workspace package" warning still fires
• 3 test files with a 28-case matrix plus regression guards

Security risks

None identified. No auth/crypto/permissions surface. The change tightens error handling (more failures surfaced, not fewer). The only new user-facing string is the error message, formatted via the standard ErrCode machinery.

Level of scrutiny

High. The resolver's DirInfo cache and module-type determination are hot-path, process-lifetime-cached, and every .js/.ts load goes through transpile_file. This PR went through four rounds of review corrections (poison leaking through nameless intermediates, 0-byte files missed, --filter warning lost, non-string-"type" breaking bun run scripts), each of which was a real regression. The final shape looks correct, but the iteration count itself signals this is subtle territory.

Other factors

• Design smell: filter_run.rs/multi_run.rs distinguish "truly poisoned" from "invalid-type-only" via !p.source_contents.is_empty() — a content heuristic rather than a dedicated flag. It works because the invalid() closure returns source: init_path_string(path, b""), but a maintainer might reasonably prefer splitting invalid into two flags as suggested in earlier review.
• Intentional behavior change: bun run <script> in a directory with a truly-malformed package.json now stops with "Script not found" instead of falling through to a parent's scripts. The PR description justifies this against npm/pnpm/yarn, but it's a user-visible change a maintainer should ack.
• Test coverage is thorough (4 invalid shapes × 4 load paths + negative cases + the two bun run regression guards), and all my prior inline comments are resolved with dedicated test cases.
• The enclosing_package_json assignment condition is now byte-identical to main (per df3fd20), so bundler/bin resolution should be unaffected — but I have not exhaustively audited every other consumer of PackageJSON::parse returning Some(invalid) where it previously returned None.

[coderabbitai]

Actionable comments posted: 2

Caution

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

⚠️ Outside diff range comments (1)

src/runtime/jsc_hooks.rs (1)

1347-1359: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win

Keep read_dir_info_package_json on enclosing_package_json
LoaderResult.package_json feeds ParseTask::init, which turns it into package_name for barrel optimization. Switching this bundler-facing hook to nearest_package_json can stop at a nameless boundary package.json and clear the inherited package name, changing bundler output for nested packages. src/runtime/jsc_hooks.rs:1347

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/runtime/jsc_hooks.rs` around lines 1347 - 1359, The
read_dir_info_package_json hook must preserve the enclosing package metadata
used by ParseTask::init and barrel optimization. In the
read_dir_info_package_json match within the resolver hook, return
dir_info.package_json() only and remove the fallback to
dir_info.nearest_package_json, while retaining the existing pointer conversion
and None handling.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/resolver/package_json.rs`:
- Around line 519-529: Introduce a public `PackageJSON::is_poisoned` predicate
that returns true when `invalid` is set and `source_contents` is empty,
documenting the distinction from parseable objects with invalid `"type"` values.
Replace the duplicated `!p.invalid || !p.source_contents.is_empty()` checks in
the `filter_run` and `multi_run` consumers with `.filter(|p| !p.is_poisoned())`.

In `@src/runtime/jsc_hooks.rs`:
- Around line 4158-4180: Update the invalid package configuration error in the
module-type resolution block to quote the package.json path using
bun_core::fmt::quote, matching the convention used by the CLI equivalent.
Replace the raw BStr path interpolation in the ERR_INVALID_PACKAGE_CONFIG
message while preserving the existing error flow and message wording.

---

Outside diff comments:
In `@src/runtime/jsc_hooks.rs`:
- Around line 1347-1359: The read_dir_info_package_json hook must preserve the
enclosing package metadata used by ParseTask::init and barrel optimization. In
the read_dir_info_package_json match within the resolver hook, return
dir_info.package_json() only and remove the fallback to
dir_info.nearest_package_json, while retaining the existing pointer conversion
and None handling.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: a10ccacf-30cd-433f-894a-0ae4f329dd8b

📥 Commits

Reviewing files that changed from the base of the PR and between 6bb5135 and 1f6d112.

📒 Files selected for processing (9)

• src/resolver/dir_info.rs
• src/resolver/package_json.rs
• src/resolver/resolver.rs
• src/runtime/cli/filter_run.rs
• src/runtime/cli/multi_run.rs
• src/runtime/jsc_hooks.rs
• test/cli/run/filter-workspace.test.ts
• test/cli/run/run_command.test.ts
• test/js/bun/resolve/resolve-error.test.ts

[robobun]

Re the outside-diff comment on src/runtime/jsc_hooks.rs:1347 (read_dir_info_package_json hook should stay on enclosing_package_json for ParseTask::init / barrel optimization):

Traced the data flow and I don't think that's where it goes. read_dir_info_package_json is the VmLoaderCtx vtable hook, called only from bundler/options.rs:get_loader_and_virtual_source, which is called only from VirtualMachine.rs:3940 (fetchWithoutOnLoadPlugins). There, lr.package_json is read exclusively for module_type (line 3950-3953) and nothing else.

ParseTask::init (bundle_v2.rs) gets its package_json from the resolver's Result via finalize_result (resolver.rs:1669-1671), which still reads dir.enclosing_package_json and is unchanged by this PR.

So keeping nearest_package_json at :1347 is correct for the one consumer (module-type) and doesn't affect barrel optimization.

[robobun]

Diff is ready for review. The two most recent CI runs each failed on a single test unrelated to this change:

• build 71376: test/js/node/test/sequential/test-net-localport.js with EADDRINUSE 127.0.0.1:44037 on linux x64-baseline (port collision)
• build 71382: test/js/node/test/parallel/test-worker-message-port-transfer-terminate.js with a JSC exception-scope assertion (!scope.exception() || !hasSlot) SIGABRT on x64-asan

Neither touches the resolver or package.json handling. All review threads are resolved; the new tests (resolve-error.test.ts, filter-workspace.test.ts, run_command.test.ts) and the previously-failing jsonc.test.ts pass on every lane where they ran. Holding off on further retriggers.

[robobun]

Closing as part of a cleanup of stale pull requests. This PR has had no new commits since 2026-07-10, it conflicts with main, and its last CI run failed. This is not a judgment on the fix itself. If the problem still reproduces on a current build, reopen this PR after a rebase or open a new one against main.