Assess, plan, evolve.

This codemod does tranformation based on changes in the utils in ethers.js ## Example Byte32 string helpers ### Before ```ts bytes32 = ethers.utils.formatBytes32String(text); text = ethers.utils.parseBytes32String(bytes32); ``` ### After ```ts bytes32 = ethers.encodeBytes32String(text); text = ethers.decodeBytes32String(bytes32); ``` Constants ### Before ```ts ethers.constants.AddressZero; ethers.constants.HashZero; ``` ### After ```ts ethers.ZeroAddress; ethers.ZeroHash; ``` Data Manipulation ### Before ```ts slice = ethers.utils.hexDataSlice(value, start, end); padded = ethers.utils.hexZeroPad(value, length); hex = hexlify(35); ``` ### After ```ts slice = ethers.dataSlice(value, start, end); padded = ethers.zeroPadValue(value, length); // v6; converting numbers to hexstrings hex = toBeHex(35); ``` Deafult AbiCoder ### Before ```ts // In v5, it is a property of AbiCoder coder = AbiCoder.defaultAbiCoder; ``` ### After ```ts // In v6, it is a static function on AbiCoder coder = AbiCoder.defaultAbiCoder(); ``` Hex Conversion ### Before ```ts hex = ethers.utils.hexValue(value); array = ethers.utils.arrayify(value); ``` ### After ```ts hex = ethers.toQuantity(value); array = ethers.getBytes(value); ``` Solidity non-standard packed ### Before ```ts ethers.utils.solidityPack(types, values); ethers.utils.solidityKeccak256(types, values); ethers.utils.soliditySha256(types, values); ``` ### After ```ts ethers.solidityPacked(types, values); ethers.solidityPackedKeccak256(types, values); ethers.solidityPackedSha256(types, values); ``` Property Manipulation ### Before ```ts ethers.utils.defineReadOnly(obj, "name", value); ``` ### After ```ts ethers.defineProperties(obj, { name: value }); ``` Above were some transformation, that were done in utilities section of ethers, now below are some cleanups and breaking changes. PS: These changes are not done using codemod. **Fetching content** Basic Fetch with Json ### Before ```ts data = await ethers.utils.fetchJson(url, json, processFunc); ``` ### After ```ts const req = new ethers.FetchRequest(url); req.body = json; req.processFunc = processFunc; const resp = await req.send(); data = resp.bodyJson; // or resp.bodyText / resp.body depending on the desired format ``` Fetch with Connection Overrides: ### Before ```ts req = { url: url, user: "username", password: "password", // etc. properties have FetchRequest equivalents }; data = await ethers.utils.fetchJson(req, json, processFunc); ``` ### After ```ts const req = new ethers.FetchRequest(url); req.setCredentials("username", "password"); req.body = json; req.processFunc = processFunc; const resp = await req.send(); data = resp.bodyJson; // or resp.bodyText / resp.body depending on the desired format ```

• ethers.js
• migration

# Remix to React Router This codemod automates most of the manual steps outlined in the Remix to React Router upgrade guide. https://github.com/remix-run/react-router/blob/dev/docs/upgrading/remix.md - It updates your dependencies from the @remix-run/* packages to react-router and @react-router/* packages in package.json. - It updates both static and dynamic imports from @remix-run/* and react-router-dom to react-router. - It handles moving removed imports from the host specific packages like @remix-run/architect, @remix-run/cloudflare etc and moving them to react-router. - It updates any vi.mock module calls to the correct package name. - It updates the scripts in your package.json if you are using the basic scripts from the Remix templates, otherwise it won't change the scripts. - It updates the import and renames the plugin in your vite.config.ts. - If you have an entry.server.tsx and/or an entry.client.tsx file in your application, it will update the main components and imports in these files, including renaming remixContext to reactRouterContext. - It renames your server file's server build import from virtual:remix/server-build to virtual:react-router/server-build. - It updates package names in compilerOptions.types in tsconfig.json files.

• migration
• remix
• +2

# Design System Migration Codemod <!-- omit in toc --> This codemod automates the migration of components between design systems. Currently supports migration from [Orbiter](https://github.com/workleap/wl-orbiter) to [Hopper](https://github.com/workleap/wl-hopper), with extensible architecture for other design system migrations. **Key Features:** - ✅ **Automated component migrations** - Updates import statements and component names - ✅ **Property transformations** - Maps old properties to new equivalents - ✅ **Migration analysis** - Generates usage reports and migration guidance - ✅ **Extensible mappings** - Support for multiple design system migrations ## Table of contents <!-- omit in toc --> - [Quick Start](#quick-start) - [Orbiter to Hopper Migration Example](#orbiter-to-hopper-migration-example) - [Usage Examples](#usage-examples) - [Migrate All Components](#migrate-all-components) - [Migrate by Category](#migrate-by-category) - [Migrate Specific Components](#migrate-specific-components) - [Target Specific Path](#target-specific-path) - [Usage Analysis](#usage-analysis) - [Contributing](#contributing) ## Quick Start ### Orbiter to Hopper Migration Example Before: ```tsx import { Div } from "@workleap/orbiter-ui"; export function App() { return <Div width="100px"/>; } ``` After: ```tsx import { Div } from "@hopper-ui/components"; export function App() { return <Div UNSAFE_width="100px"/>; } ``` ## Usage Examples The default mapping table is set. for Orbiter to Hopper. If you want to run it for other mappings, you need to set it through the `mappings` parameter. ### Migrate All Components ```bash pnpx codemod workleap/migrations ``` ### Migrate by Category ```bash # Migrate layout components (Flex, Grid, Div, etc.) pnpx codemod workleap/migrations -c layout # Migrate button components pnpx codemod workleap/migrations -c buttons # Other categories: visual, menu, overlay, tags, disclosure ``` ### Migrate Specific Components ```bash # Single component pnpx codemod workleap/migrations -c Div # Multiple components pnpx codemod workleap/migrations -c Div,Text,Button ``` ### Target Specific Path Run the command in the desire path or pass the target path with the `-t` argument. ```bash pnpx codemod workleap/migrations -t /app/users ``` ## Usage Analysis Generate usage reports to understand your migration scope: ```bash # Basic analysis pnpx codemod workleap/migrations -a usage-report.json -n 1 # Detailed analysis with file locations pnpx codemod workleap/migrations -a usage-report.json --deep true -n 1 # Project-specific analysis pnpx codemod workleap/migrations -a usage-report.json --project frontend-team -n 1 # Using hopper mappings for analysis pnpx codemod workleap/migrations -a hopper-usage.json --mappings hopper -n 1 # Analyze unmapped components only pnpx codemod workleap/migrations -a unmapped-components.json --filter-unmapped components -n 1 ``` **Key Parameters:** | Parameter | Description | Example | |-----------|-------------|---------| | `-a <filename>` | Output analysis to JSON file | `-a usage-report.json` | | `-c <components>` | Specify components to migrate | `-c layout` or `-c Div,Text` | | `-t <path>` | Target specific path | `-t /app/users` | | `--project <name>` | Track usage by project/team. It is pretty usefule when you analysis multiple repos and want to aggregate analysis results. | `--project frontend-team` | | `--mappings <type>` | Specify mapping table (`orbiter-to-hopper` (default) or `hopper`) | `--mappings hopper` | | `--deep true` | Include file locations | `--deep true` | | `--filter-unmapped <type>` | Show only unmapped items | `--filter-unmapped props` | | `-n 1` | Use single thread (required for analysis) | `-n 1` | **Sample Analysis Output:** ```json { "overall": { "usage": { "components": 15, "componentProps": 45, "functions": 3, "types": 8 } }, "components": { "Text": { "usage": { "total": 25, "projects": { "frontend-team": 15, "mobile-app": 10 } }, "props": { "size": { "usage": 20, "values": { "lg": { "usage": { "total": 12 } }, "md": { "usage": { "total": 8 } } } } } }, "Button": { "usage": { "total": 18, "projects": { "frontend-team": 18 } } } }, "functions": { "useResponsive": { "usage": { "total": 8, "projects": { "frontend-team": 5, "mobile-app": 3 } }, "values": { "useResponsive()": { "usage": { "total": 8 } } } } }, "types": { "ComponentProps": { "usage": { "total": 12, "projects": { "frontend-team": 8, "mobile-app": 4 } } } } } ``` ## Contributing To add support for other design system migrations or contribute to existing ones, see [CONTRIBUTING.md](CONTRIBUTING.md) for detailed guidelines.