fix(noImportCycles): prevent flagging on single file import cycling

[emilyinure]

Summary

Allows cases where a cycling import is contained to a single file.

fixes #6569

Test Plan

Snap tests in /specs/nursery/noImportCycles/valid.js

export function bar() {
  return 1;
}

export * as bar from "./valid"

import { foobar } from "./valid"

foobar.bar();

Passing, along with existing test cases passing.

[changeset-bot]

🦋 Changeset detected

Latest commit: 92d3e18

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 13 packages

Name	Type
@biomejs/biome	Patch
@biomejs/cli-win32-x64	Patch
@biomejs/cli-win32-arm64	Patch
@biomejs/cli-darwin-x64	Patch
@biomejs/cli-darwin-arm64	Patch
@biomejs/cli-linux-x64	Patch
@biomejs/cli-linux-arm64	Patch
@biomejs/cli-linux-x64-musl	Patch
@biomejs/cli-linux-arm64-musl	Patch
@biomejs/wasm-web	Patch
@biomejs/wasm-bundler	Patch
@biomejs/wasm-nodejs	Patch
@biomejs/backend-jsonrpc	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codspeed-hq]

CodSpeed Performance Report

Merging #6765 will not alter performance

_{Comparing emilyinure:fix-single-file-import-cycle (92d3e18) with main (0c8349e)}

Summary

✅ 58 untouched
⏩ 95 skipped¹

Footnotes

1. 95 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[arendjr]

Thanks!

Do you think it makes sense to restrict this exception to exports only? It would be sufficient for the use case from #6569, so I wonder if there could ever be a reason why you'd want to import from the same file?

[emilyinure]

I will look into it, thank you for the review

[ematipico]

@emilyinure any updates?

[coderabbitai]

Actionable comments posted: 0

♻️ Duplicate comments (1)

.changeset/icy-results-wonder.md (1)

5-19: Example doesn't demonstrate self-referential export.

The changeset description says "Allow files to export from themselves", but the example shows exporting from './test' while the file is example.js. This doesn't demonstrate the self-reference scenario that the fix addresses.

As suggested in the past review comment, consider updating the example to show an actual self-reference:

 **example.js**
 ```js
 export function example1() {
   return 1;
 }
 
 export function example2() {
   return 2;
 }
 
-export * as Example from './test';
+export * as Example from './example';

Alternatively, if the file should export from itself, use:

```js
export * as Example from './example.js';

This would clearly demonstrate the fix for self-referential exports.

Based on learnings

🧹 Nitpick comments (1)

crates/biome_js_analyze/src/lint/nursery/no_import_cycles.rs (1)

173-177: Guard logic correctly prevents false positives for self-references.

The implementation properly identifies single-file cycles by checking if the stack is empty (no intermediate files) and the start path matches the resolved path. This aligns with the PR objective to fix issue #6569.

Minor suggestion for clarity: since at this point resolved_path == ctx.file_path() (from line 172), you could compare paths directly:

-if stack.is_empty() && start_path.as_str() == resolved_path {
+if stack.is_empty() && start_path == resolved_path {

or even more explicitly:

-if stack.is_empty() && start_path.as_str() == resolved_path {
+if stack.is_empty() && start_path == ctx.file_path() {

This avoids the string conversion and makes the intent clearer.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c8d0e01 and 29162e9.

⛔ Files ignored due to path filters (1)

• crates/biome_js_analyze/tests/specs/nursery/noImportCycles/valid.js.snap is excluded by !**/*.snap

📒 Files selected for processing (3)

• .changeset/icy-results-wonder.md (1 hunks)
• crates/biome_js_analyze/src/lint/nursery/no_import_cycles.rs (1 hunks)
• crates/biome_js_analyze/tests/specs/nursery/noImportCycles/valid.js (1 hunks)

🧰 Additional context used

🧠 Learnings (1)

📓 Common learnings

Learnt from: arendjr
Repo: biomejs/biome PR: 7593
File: crates/biome_service/src/workspace/server.rs:1306-1306
Timestamp: 2025-09-25T12:32:59.003Z
Learning: In the biomejs/biome project, do not flag compilation errors during code review as they are handled by the existing test infrastructure and CI. Focus on other code quality aspects instead.

🧬 Code graph analysis (1)

crates/biome_js_analyze/tests/specs/nursery/noImportCycles/valid.js (1)

crates/biome_js_analyze/tests/specs/nursery/noImportCycles/invalidFoobar.js (1)

• bar (7-9)

🪛 markdownlint-cli2 (0.18.1)

.changeset/icy-results-wonder.md

9-9: Emphasis used instead of a heading

(MD036, no-emphasis-as-heading)

🔇 Additional comments (2)

crates/biome_js_analyze/src/lint/nursery/no_import_cycles.rs (1)

180-186: Type annotation improves code clarity.

The explicit type annotation for the paths collection enhances readability without changing behavior.

crates/biome_js_analyze/tests/specs/nursery/noImportCycles/valid.js (1)

7-15: The review comment is based on a misunderstanding of the test's purpose.

This is a test file for the noImportCycles linter rule specifically, not a validation of general JavaScript correctness. The test file is named "valid.js" because it should not trigger the noImportCycles rule—and it doesn't. The snap file confirms the test expects zero diagnostics.

The rule only checks for circular imports. The three concerns raised (name collision, missing export, mismatched structure) are semantic/syntax issues that:

1. Fall outside the scope of the noImportCycles rule
2. Would be caught by different linting rules if needed
3. Are irrelevant to whether valid.js participates in an import cycle

The file correctly imports from ./invalidFoobar, which has a cycle (invalidFoobar ↔ invalidBaz), but that cycle does not lead back to valid.js, so the rule correctly produces no diagnostics.

Likely an incorrect or invalid review comment.

[dyc3]

Great work!