crates/biome_project_layout/src/project_layout.rs (1)

74-96: Pin the layout once for the whole walk.

The rustdoc is nicely clear, but the implementation re-pins the concurrent map on every ancestor hop via get_node_manifest_for_package(). Holding one pin here matches the neighbouring lookup helpers and avoids a bit of needless churn.

Suggested tidy-up

     pub fn get_dependency_manifest(
         &self,
         project_dir: &Utf8Path,
         dependency_name: &str,
     ) -> Option<PackageJson> {
-        for ancestor in project_dir.ancestors() {
-            let dep_path = ancestor.join("node_modules").join(dependency_name);
-            if let Some(manifest) = self.get_node_manifest_for_package(&dep_path) {
-                return Some(manifest);
-            }
-        }
-        None
+        let packages = self.0.pin();
+        project_dir.ancestors().find_map(|ancestor| {
+            let dep_path = ancestor.join("node_modules").join(dependency_name);
+            packages
+                .get(dep_path.as_path())
+                .and_then(|data| data.node_package.as_ref())
+                .and_then(|node_package| node_package.manifest.as_ref())
+                .cloned()
+        })
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_project_layout/src/project_layout.rs` around lines 74 - 96, The
loop in get_dependency_manifest re-acquires the concurrent layout pin on every
ancestor by calling get_node_manifest_for_package repeatedly; instead, acquire
the layout pin once before the for ancestor loop (e.g. obtain the pinned guard
from self.layout or whatever pin API the concurrent map exposes), then either
call a variant of get_node_manifest_for_package that takes a reference to that
pinned guard or pass the guard into the loop so each iteration reuses the same
pin; update get_dependency_manifest to hold that single pin for the whole walk
and adjust get_node_manifest_for_package signature if needed to accept the
pinned guard.

crates/biome_json_analyze/tests/spec_tests.rs (1)

163-175: Harden project_layout_for_json_test for real-world node_modules layouts.

The current one-level scan skips scoped packages (node_modules/@scope/pkg), and ok()? in the loop can bail out the whole helper on a single bad entry. A continue-based walk (plus scoped package handling) would make these tests less brittle.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_json_analyze/tests/spec_tests.rs` around lines 163 - 175, The
loop that builds the test ProjectLayout should be hardened: replace the current
for-entry usage that uses ok()? and thus can return early, with a continue-based
walk that skips individual broken entries instead of bailing the whole helper,
and add handling for scoped packages (directories whose name starts with '@') by
iterating their child package directories as well; specifically, update the loop
that reads std::fs::read_dir(node_modules_dir) to (a) on any read_dir, try_from,
or read_to_string error just continue rather than using ok()? to return, (b)
when an entry is a directory whose file_name starts with '@', iterate its
entries and process each child package the same way, and (c) continue to call
project_layout.insert_node_manifest(pkg_dir, manifest) only for successfully
parsed package.json files.

crates/biome_json_analyze/src/lint/nursery/no_untrusted_licenses.rs (1)

337-346: The missing-license diagnostic needs a “what now?” line.

This explains the problem and the risk, but not the next step. A short remediation note would make the warning much more actionable.

✏️ Suggested tweak

             .note(markup! {
-                "Dependencies without a license field may have unknown legal restrictions."
+                "Dependencies without a license field may have unknown legal restrictions. Review the dependency manually, replace it, or contact the maintainer before using it."
             }),

Based on learnings, "Implement the `diagnostic` function to convert signals into RuleDiagnostic instances with informative messages. Always follow the three pillars: explain WHAT the error is, explain WHY it's triggered, and tell the user WHAT to do"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_json_analyze/src/lint/nursery/no_untrusted_licenses.rs` around
lines 337 - 346, The missing-license diagnostic created in the Reason::Missing
arm (using RuleDiagnostic::new with state.range and markup referencing dep and
group) explains the issue and risk but lacks remediation; update this diagnostic
to include a short actionable "what now?" line by chaining a .help or an
additional .note that tells users how to fix it (e.g., add a license field to
the dependency's manifest or contact the package maintainer, or pin to a
known-licensed alternative) so the RuleDiagnostic produced for Reason::Missing
gives WHAT is wrong, WHY it matters, and a clear WHAT TO DO next.