🦋 Changeset detected

Latest commit: 4190543

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

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

Action	Severity	Alert  (click "▶" to expand/collapse)
Warn		Obfuscated code: npm js-beautify is 100.0% likely obfuscated Confidence: 1.00 Location: Package overview From: package.json → npm/js-beautify@1.14.7 ℹ Read more on: This package | This alert | What is obfuscated code? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/js-beautify@1.14.7. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

Binary Sizes

Commit: 1b29e25

Merging this PR will not alter performance

✅ 219 untouched benchmarks

_{Comparing kdy1/react-compiler-swc-port (4190543) with main (62eeee1)}

Addressed review #11687 (review) in 710d12c:

• ignore type-only imports in memo-cache import detection and import reuse
• apply eslint-disable-next-line suppression to the following function (and consume it once)
• added regression tests for both cases

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	glob@​8.1.0
	eslint@​8.57.0
	jest@​29.7.0
	expect@​27.5.1
	npm-run-all@​4.1.5
	sourcemap-validator@​2.1.0
	react@​17.0.2
	husky@​8.0.3 ⏵ 7.0.4	+1
	regenerator-runtime@​0.13.11
	reflect-metadata@​0.1.14
	@​types/​node@​20.14.2 ⏵ 20.12.12				+1
	swc-plugin-coverage-instrument@​0.0.26
	js-beautify@​1.14.7
	ts-node@​10.9.1
	prop-types@​15.8.1
	source-map-support@​0.5.21
	yaml@​2.3.1 ⏵ 2.4.5	+1
	source-map@​0.7.4
	terser@​5.17.6
	semver@​7.7.2 ⏵ 7.5.4
	typescript@​4.9.5 ⏵ 5.3.3	+1
	prettier@​3.3.2 ⏵ 2.8.8	+2		+1
	cspell@​5.21.2
	mocha@​9.2.2
	lint-staged@​14.0.1 ⏵ 12.5.0				+8

View full report

PR Review: feat(react-compiler): scaffold SWC port of Babel entrypoint

Overall this is a well-structured scaffold that faithfully mirrors the Babel plugin's entrypoint logic. The architecture is clean: options parsing, entrypoint orchestration, and pipeline stage stubs are well-separated. Here are findings organized by category:

Code Quality

1. Significant code duplication between compile_named_function and compile_arrow (program.rs). The two methods share ~90% of their logic (suppression checking, directive parsing, opt-in/opt-out, compilation mode selection, error recording, codegen application, gating). Consider extracting the shared logic into a helper that takes a closure or trait object for the AST-specific parts.

2. CompilerDiagnostic struct appears unused (error.rs:77-80). It is defined and re-exported from lib.rs but never constructed anywhere. If it's a placeholder for future use, a #[allow(dead_code)] or a brief doc comment explaining intent would clarify.

3. _script_require_stub in imports.rs is dead code with #[allow(dead_code)]. It also constructs a Pat::Invalid node, which would produce broken output if ever called. Consider removing it entirely or at minimum documenting what it's a placeholder for.

4. collect_top_level_names (program.rs) duplicates the Module/Script match logic. A small helper like fn top_level_stmts(program) -> impl Iterator<Item = &Stmt> would reduce this.

Potential Bugs

5. Double visitation in ReactCompilerVisitor (lib.rs:49-57): compile_program already runs program.visit_mut_with(&mut compiler) internally (line ~655 in program.rs), which uses ProgramCompiler as the visitor. Then lib.rs:57 calls program.visit_mut_children_with(self) again. Since ProgramCompiler already recurses into nested functions via its VisitMut impl, this second traversal appears redundant and could cause functions to be visited/compiled twice. This should be verified — if compile_program is the complete pass, the outer visit_mut_children_with should likely be removed.

6. Arrow concise-body conversion clones the body (program.rs, compile_arrow):

   let expr = match *arrow.body.clone() {
       BlockStmtOrExpr::Expr(expr) => expr,
       ...
   };

   This clones the entire body just to destructure it. You could use std::mem::replace or match on a mutable reference to avoid the clone.

7. is_hook_name("use1") returns true (utils/mod.rs): The function accepts digits after "use" (e.g., use1State), matching c.is_ascii_digit(). This seems intentional to match upstream React behavior, but it might be worth a unit test to document this edge case.

Performance

8. Excessive cloning in the pipeline stubs: Since all pipeline stages (HIR, SSA, inference, optimization, validation, reactive_scopes) are currently no-ops that pass through the AST unchanged, the Function is cloned at least 3 times (HIR lower clones it, build_reactive_function clones body, codegen_function moves it, then apply_codegen_to_function clones params/body back). For the scaffold stage this is fine, but as real logic is added, consider taking ownership rather than cloning.

9. suppressions_for_span iterates all suppressions for every function. For large files with many comments, consider pre-sorting suppressions by byte position for binary search.

10. Atom::new(...) usage: Per AGENTS.md, when creating Atom instances prefer &str over String. Several places do Atom::new(imported_name) or Atom::from(import_specifier_name) from &str, which is fine. But Atom::new(local_hint) in add_import_specifier and Atom::new(module_name) in import creation could use Atom::from(...) from &str directly — worth double-checking these go through the interning fast path.

Security

11. sync_fixtures.sh pipes gh api output through jq and base64 --decode to extract file content. The name variable comes from the manifest file and is used directly in API paths and filesystem paths. While the manifest is checked into the repo, if it were ever user-editable, path traversal (../../) in fixture names could write outside OUT_DIR. Consider validating that name contains no path separators.

Test Coverage

12. Good inline unit test coverage for options parsing, suppression detection, import handling, and program compilation. The fixture harness covers basic-component, module-opt-out, and dynamic-gating-invalid cases.

13. Missing test coverage for:

    • Arrow function compilation (the compile_arrow path)
    • CompilationMode::Syntax and CompilationMode::All branches
    • Export default declarations/expressions
    • Nested function depth tracking (functions inside classes)
    • validate_restricted_imports with actual blocklisted imports
    • The sources filename filter with both matching and non-matching patterns
    • PanicThresholdOptions::AllErrors and CriticalErrors actually triggering fatal errors
    • The outlined function name deduplication logic (insert_queued_outlined with name collisions)

14. Fixture test runner (tests/fixture.rs) uses a single #[test] that loops over all fixtures. Consider using testing::fixture macro (per project conventions) so each fixture gets its own test name for better failure reporting.

Minor Nits

• to_string_lossy() on import_decl.src.value in validate_restricted_imports is unnecessary since Atom already implements Display.
• find_directive_disabling_memoization takes &Option<Vec<String>> — prefer Option<&[String]> for the parameter type to avoid requiring the caller to have an owned Option<Vec<...>>.

Overall: solid scaffolding with good separation of concerns. The main actionable items are the potential double-visitation bug (#5), the large duplication between named/arrow compilation (#1), and expanding test coverage for the various compilation mode branches (#13).