A search finds a function definition but no calls under that name. What would you need to know before removing it?
Write a brief prediction before opening the explanation.
Read the lesson
Start with the behavior and follow the boundary
Name the behavior you want to understand: a save request, a notification or a job being queued. Locate its entry point, then follow the values and functions that carry it across modules. Record the caller, the binding it imports and the side effect it reaches. Similar spelling is a clue, not a dependency map. A comment and a runtime import can match the same search but provide very different evidence.
Choose tools for the question
Text search is useful for locating names, route strings and configuration keys. Reading import and export statements can resolve aliases. If your environment has working symbol navigation, definition and reference results can help disambiguate bindings; inspect the returned code and the tool's coverage before relying on it. This lesson does not assume an editor plugin or language server is installed. You can build a small, explicit trace by reading files without adding tools or changing configuration.
An empty result has a scope
A reference search can miss string-based registration, generated code, consumers outside the checkout or files excluded from its index. State where and how you searched. For a registered handler, follow the registry key and the dispatch code as well as the function name. Before removing behavior, check whether a focused test actually exercises that path. A passing test unrelated to the handler does not establish that its removal is safe. Stop at an unresolved external boundary and describe what evidence would resolve it.
Treating no text or reference matches as proof that a symbol is unused, or installing an assumed navigation tool without checking the environment.
Make the request actionable
A weak starting brief: Find unused functions and delete anything with no search matches.
This example is an adaptable request, not evidence that a runtime action has executed.
A caller under another name
Simulated repository:
notify.ts: export function deliver(message) { return transport.send(message) }
public.ts: export { deliver as notify } from './notify'
checkout.ts: import { notify as sendReceipt } from './public'; sendReceipt(receipt)
notes.md: 'deliver is legacy'
An exact search for deliver( finds only its definition. The task is to explain receipt delivery before changing its retry handling. No edits or tests have run.Simulated scenario · No repository access or command execution
Loading your saved lesson progress…