Product
Reading a Codebase Without Running It
Point the X-ray at a source file or a zip and it parses the code in your browser into a file tree, a symbol index and a relationship map, with four checks that cite the exact line.
Applies to Novus Learn 0.1.0
The question a new codebase actually poses
Copy linkWhen you open an unfamiliar repository the first question is never what does this line do. It is which of these files matter, what calls what, and where the thing I am looking for is defined. Reading files top to bottom answers that slowly and expensively.
The X-ray answers it structurally. Give it one source file or a zip archive and it parses the code in this browser into a real file tree, a symbol index, a source view and a relationship map. Nothing is rewritten, nothing is graded, and every observation stays linked to the line it came from.
What it parses
Copy linkJavaScript and TypeScript, including the module and component variants: js, jsx, mjs and cjs on one side, ts, tsx, mts and cts on the other. The parser is configured per file extension rather than guessed, which matters more than it sounds: in a plain TypeScript file angle brackets are a type assertion, and in a component file they are an element, and a parser that gets that backwards produces nonsense for half a repository.
It is a reading tool, not a runner. Nothing you give it executes. If you want to run something, the scratchpad is the sandbox for that, and it is deliberately a separate place: mixing analysis and execution in one surface would make it very easy to run something you only meant to look at.
Four checks that cite their evidence
Copy link- Exported declarations with no doc comment, which is where an unfamiliar API is hardest to read.
- Files that export something nothing in the codebase imports, the classic shape of code that is already dead.
- Functions and methods with no call site anywhere in the source you provided.
- Import cycles between files, with the cycle itself named.
Why every finding carries a line number
Copy linkA static check that says a function is unused, with no way to jump to it, is an opinion. The checks here each cite a file and a line, which turns the output into something you can act on and, just as importantly, something you can disprove in seconds when it is wrong.
They are honest about scope too. Unimported means unimported in the source you provided, which is not the same as unused in the world: a file that is the entry point of a package will always look unimported from inside it. The check names what it examined rather than making a claim about your project as a whole.
Nothing you upload leaves the browser
Copy linkParsing happens on your device under the same same-origin policy every other upload here uses. Source code is exactly the kind of material people are right to be careful about, and the guarantee is structural rather than a promise in a policy: there is no upload endpoint for it to go to.
The resulting map is a local project like any other, so it appears in My Library and can be deleted from there.
What a structural view shows that reading does not
Copy linkThree things fall out of a symbol and call graph that are genuinely hard to see by reading. The first is which files everything depends on, which is almost always where the design lives and almost never where the interesting-looking filenames are. The second is the shape of the seams: a module that everything imports and that imports nothing is a foundation, and one that imports half the project is usually doing too much.
The third is the surprise. Every unfamiliar codebase has at least one file that matters far more than its name suggests, and a graph surfaces it immediately where a reading pass finds it on day three. None of this is a substitute for reading the code; it is a way of deciding which code to read first, which is the actual bottleneck.
Where it fits beside the course
Copy linkReading real code is the step most learning material skips. The written course teaches the language with exercises graded on your device, and the X-ray is what you point at somebody else's project once the syntax has stopped being the obstacle.
A good first exercise: take a small open-source library you already use, run the import-cycle and uncalled-function checks, and read the three files with the most inbound edges. That is usually the whole design.
A good second exercise is to point it at something you wrote six months ago. The undocumented-export check is unkind and accurate, and the list it produces is a reasonable to-do list for making your own project readable by somebody else.