Contents
Library upgrades often combine straightforward name changes with decisions that depend on application behavior. A request property may simply have a new name, while middleware registration or component lifecycle behavior can require understanding how the surrounding program works. The API Migration Mapper is designed to separate those cases rather than present every changed token as a complete migration.
The page runs locally in your browser. It has no backend, network requests, or model calls. Paste a JavaScript or TypeScript snippet, choose a preset, and select Map migration. The result includes a rewritten snippet, a findings table, a MANUAL REVIEW list, and a mechanical coverage percentage. Each finding records a line number, rule ID, before text, and after text. Any construct listed for manual review is left untouched by the mapper’s rules.
What the presets change
The Express 4 → Fastify preset applies a short list of mechanical substitutions. It maps route registrations such as app.get(...) and app.post(...) to their fastify counterparts. It maps the selected request properties—params, query, body, and headers—from req to request. It also maps res.send(...) to reply.send(...), res.json(...) to reply.send(...), and numeric res.status(...) calls to reply.code(...).
The res.json finding notes that Fastify serializes objects sent in a reply. Fastify’s Reply documentation describes the reply interface, including sending a payload and setting a response code. Its Request documentation documents the request object and its properties. The mapper only handles the listed property names and calls; it does not infer a complete Fastify handler signature or configure a server.
Some Express patterns are deliberately not rewritten. app.listen(...) needs a manual adaptation because Fastify’s listening API is asynchronous and takes an options object. app.use(...) is flagged because Fastify’s plugin registration and encapsulation model is not a safe one-for-one substitution. Calls to next(...), unknown res methods, and cases where res is passed as an argument are also sent to MANUAL REVIEW. These cases need decisions about control flow, middleware, or the role of the response object.
The React class → hooks preset handles a recognized class with a render method. It can turn a simple class declaration into a function component, convert a simple constructor state object into individual useState declarations, and map object-form setState calls to setter calls. It maps this.props. to props. and represents componentDidMount as an effect with an empty dependency array. If a componentWillUnmount body is present, it is placed in the cleanup returned from that effect.
These are limited syntax-level transformations, not a general class-component conversion. React’s Component reference describes the class component API, while the useState reference documents state variables and their setters. The useEffect reference explains effects and cleanup. Those documents provide the concepts behind the preset, but they do not imply that mechanically moving code preserves an application’s behavior.
The custom rename table accepts one old_name -> new_name rule per line. A rule matches a whole identifier using word boundaries, then reports each replacement with its line number. This preset performs no scope analysis. Strings and comments are not special-cased, so a matching identifier in either will also be replaced. Review those edits carefully, and avoid broad rules when a name is also used as text.
Reading the score and review list
Mechanical coverage is calculated as rewritten findings divided by rewritten findings plus manual-review findings. It measures the selected rule table’s coverage of detected constructs, not the correctness, safety, or completeness of a migration. A high score does not mean the result compiles, preserves behavior, or accounts for every API change. The score can also be zero when there are no findings to count.
The tool does not parse the language or understand types, scopes, overloads, project configuration, or runtime behavior. Its rule-based matches can miss constructs, and code with unfamiliar formatting or nested expressions may not fit the supported shapes. A reported rewrite is a candidate edit for review, not a guarantee of validity. A construct that requires judgment should be added to MANUAL REVIEW rather than guessed at.
A practical review workflow
Start with a small, representative snippet and choose the matching preset. Use one of the example buttons if you want to see the output format before pasting code. For custom renames, enter the replacement table and check the warning about strings and comments. After mapping, compare each finding against the original code. Then work through every manual-review item and make the required framework-specific changes yourself.
For a real upgrade, consult the framework’s current documentation and consider the surrounding code that the snippet does not show. In particular, verify handler arguments, asynchronous behavior, lifecycle timing, dependencies, and any middleware or plugin registration. Keep the tool’s output as a review aid, not as the migration plan by itself. The version-upgrade roadmap describes this feature’s place among the planned developer tools.
This review is based on official documentation; the tool was not run against production codebases. The mapper makes no claim that a rewritten snippet compiles or behaves the same as its original. Its purpose is narrower: make a defined set of substitutions visible, show what was changed, and call out selected patterns that require a human decision.
📖 Related Reads
- ToolBrain — tool reviews, LLM comparisons, and AI workflow guides
Cross-links automatically generated from CodeIntel Log.
