Thirteen seconds of npm setup does not establish a working Firefox
Firefox's npm dependency step finished in 13 seconds in our sandbox. That is useful repository evidence, but it leaves the question a source contributor cares about unanswered: can this environment produce and run the browser? Our runner skipped build and tests because it found no corresponding script or target. There is no compiled-browser result behind that installation time.
Mozilla's official source repository is the right place to inspect Firefox or begin a contribution. Someone choosing a browser for everyday use needs different evidence, such as how their sites and extensions behave. We did not collect that evidence. This review answers whether our repository run clears the way for development, and where the documented workflow differs from the runner's npm route.
What happened when we ran it
Our October 28, 2026 run at commit be3847d completed npm installation in 13 seconds, recorded 948 dependencies and measured 291 MB on disk. Build and tests were skipped because no script or target was found. The correct reading is a successful dependency step with unmeasured browser compilation and test execution.
The recorded checkout contained 476,281 files, approximately 39,638,734 lines of source and 3,494.8 MB. The scan classified the ecosystem as Node with npm, detected one CI workflow file, and found no Dockerfile or tests directory. Those detection results describe what the scanner recognized. They do not establish the absence of browser infrastructure elsewhere in the tree.
The sandbox configuration specified 3 CPUs, 8 GB RAM and image lab-node:22. Actual runtime versions require the toolchain logs. The label alone does not establish a Node version, and the record does not show the resources needed for a complete supported browser development setup.
npm audit reported 0 known vulnerabilities, with 0 critical, high, moderate or low findings. That is the result of the recorded npm audit. It does not assess every component in a browser source tree, prove the browser safe, or provide a privacy finding. The npm footprint also must not become an advertised full Firefox development footprint.
Mozilla directs contributors through bootstrap and mach
The contributor quick reference describes bootstrapping the source environment and using mach for development. It separates setup paths by operating system and points contributors toward platform-specific prerequisites. We did not reproduce that workflow, so we cannot award it a setup score on the strength of npm installation alone.
This distinction changes the next action. If your goal is a Firefox patch, use Mozilla's supported setup route for your platform and the component you intend to change. A successful package-manager command from a generic runner is too small a milestone to replace that preparation. Keep its result, but label its scope.
Mozilla also distinguishes artifact mode from work that changes C++ or Rust. That is a documented development choice, rather than a measured shortcut in our sandbox. Identify the kind of change first. It determines which instructions you should follow and prevents a contributor from drawing platform conclusions from this npm-only result.
Bugzilla is the bug tracker, even with a GitHub repository
The Firefox README directs bug reports to Bugzilla. It links Firefox Source Docs as the primary documentation and an introductory Matrix channel for development questions. A contributor expecting every part of the workflow to happen through GitHub will need to adjust before submitting work.
The contributor quick reference describes Bugzilla and Phabricator accounts and a patch-review process. This is relevant operating effort even though it is separate from installing dependencies. If your team is considering a small upstream change, agree who will own the report and respond to review. A local edit without a route through that process does not become an upstream fix.
GitHub metadata records a last push on October 29, 2026, and the recent pull-request feed contains October 28 activity linked to Bugzilla work. That supports ongoing repository activity. It does not measure maintainer responsiveness, review turnaround or the size of the contributor community. GitHub's combined issues-and-PRs count would be especially poor evidence of Firefox's bug backlog when the project directs bugs elsewhere.
The latest-release endpoint returned no GitHub release. The README independently links browser downloads, including Nightly. An empty release endpoint therefore gives no basis for calling Firefox abandoned or unavailable.
Zen and Brave are different contribution destinations
Zen Browser describes itself as Firefox-based. Consider it if the separate Zen project is what you want to change. That relationship does not establish equivalent behavior, compatibility or maintenance arrangements, and we have no comparative measurements to recommend it as faster or easier.
Brave Browser says its repository holds issues, releases and the wiki; source contributions belong in brave/brave-core. That distinction matters when selecting a checkout. A repository name can identify a browser without containing the source tree you expect to work in.
For a Firefox contribution, pick a concrete component and follow Mozilla's platform instructions. Record browser compilation and execution separately from npm setup. Until those results exist, the honest outcome from our run is a successful dependency step and an unanswered browser-development question.