Assess, plan, evolve.

A codemod which makes the array search operation more optimal and efficient, by converting the array into a set and executing the set's has method to find the desired element. ### Before ```ts //intialize a set using the elements of that array //check in the set instead of the array and use the has method instead of the includes method const isElmement = array.includes(elementToCheck); ``` ### After ```ts const set = new Set(array); const isElmement = set.has(elementToCheck); ```

This codemod updates synchronous MongoDB operations in a Meteor project to use their asynchronous counterparts, making the code compatible with modern JavaScript best practices (using `async/await`). It transforms methods such as `find`, `findOne`, `insert`, `update`, `remove`, and `upsert` to their asynchronous equivalents by appending `Async` to method names and introducing `await`. ### Example This codemod converts synchronous MongoDB queries and updates into asynchronous methods for better code readability, performance, and error handling. ### Before ```ts const docs = MyCollection.find({ _id: "123" }).fetch(); const doc = MyCollection.findOne({ _id: "123" }); ``` ### After ```ts const docs = await MyCollection.find({ _id: "123" }).fetchAsync(); const doc = await MyCollection.findOneAsync({ _id: "123" }); ``` ### Transformations This codemod handles various MongoDB operations and converts them into asynchronous functions. #### Example 1: Fetching documents **Before:** ```ts const docs = MyCollection.find({ _id: "123" }).fetch(); ``` **After:** ```ts const docs = await MyCollection.find({ _id: "123" }).fetchAsync(); ``` #### Example 2: Fetching a single document **Before:** ```ts const doc = MyCollection.findOne({ _id: "123" }); ``` **After:** ```ts const doc = await MyCollection.findOneAsync({ _id: "123" }); ``` #### Example 3: Updating documents **Before:** ```ts MyCollection.update({ _id: "123" }, { $set: { name: "John" } }); const updatedDocument = MyCollection.findOne({ _id: "123" }); ``` **After:** ```ts await MyCollection.updateAsync({ _id: "123" }, { $set: { name: "John" } }); const updatedDocument = await MyCollection.findOneAsync({ _id: "123" }); ``` #### Example 4: Inserting, updating, removing, and upserting documents **Before:** ```ts MyCollection.insert({ name: "Jane", age: 30 }); MyCollection.update({ _id: "123" }, { $set: { name: "John" } }); MyCollection.remove({ _id: "123" }); MyCollection.upsert({ _id: "123" }, { $set: { name: "John" } }); ``` **After:** ```ts await MyCollection.insertAsync({ name: "Jane", age: 30 }); await MyCollection.updateAsync({ _id: "123" }, { $set: { name: "John" } }); await MyCollection.removeAsync({ _id: "123" }); await MyCollection.upsertAsync({ _id: "123" }, { $set: { name: "John" } }); ``` --- This codemod simplifies migration from synchronous MongoDB methods to their asynchronous versions, improving performance and allowing better control over the code execution flow.

# es-set-tostringtag Codemod ## Introduction This codemod removes the dependency on the `es-set-tostringtag` package and replaces its usage with the native `Object.defineProperty` and `Symbol.toStringTag`. By doing so, it eliminates unnecessary dependencies and leverages built-in ES features, enhancing performance and reducing bundle size. ### Before ```javascript import setToStringTag from 'es-set-tostringtag'; const myObject = {}; setToStringTag(myObject, 'MyObject', { force: true }); ``` ### After ```javascript const myObject = {}; Object.defineProperty(myObject, Symbol.toStringTag, { configurable: true, enumerable: false, value: 'MyObject', writable: false, }); ```

Replace incorrect or non-idiomatic `set.length` reads with `set.size` for variables/expressions statically known to be `Set` instances in JavaScript/TypeScript codebases, improving correctness and code quality.

This codemod migrates the `target` property in Webpack configurations from a function to `false` and moves the function to the `plugins` array. In Webpack 4, it was possible to set the `target` property to a function. However, in Webpack 5, this approach is no longer supported. Instead, the `target` should be set to `false`, and the function should be included in the `plugins` array. This codemod automates the transformation of Webpack configurations to adhere to the new specification. ## Example ### Before ```ts module.exports = { target: WebExtensionTarget(nodeConfig), }; ``` ### After ```ts module.exports = { target: false, plugins: [WebExtensionTarget(nodeConfig)], }; ``` , ### Before ```ts const WebExtensionTarget = require("webpack-extension-target"); module.exports = { target: WebExtensionTarget(nodeConfig), mode: "development", output: { filename: "bundle.js", }, }; ``` ### After ```ts const WebExtensionTarget = require("webpack-extension-target"); module.exports = { target: false, plugins: [WebExtensionTarget(nodeConfig)], mode: "development", output: { filename: "bundle.js", }, }; ``` , ### Before ```ts module.exports = { target: WebExtensionTarget(nodeConfig), optimization: { splitChunks: { chunks: "all", }, }, }; ``` ### After ```ts module.exports = { target: false, plugins: [WebExtensionTarget(nodeConfig)], optimization: { splitChunks: { chunks: "all", }, }, }; ``` , ### Before ```ts module.exports = { target: CustomTargetFunction(config), }; ``` ### After ```ts module.exports = { target: false, plugins: [CustomTargetFunction(config)], }; ```

Using builtin:swc-loader offers better performance compared to the babel-loader and the external swc-loader, as it avoids frequent communication between JavaScript and Rust. ### Before ```ts // Remove the use array and redefine all the given configations below the test key pair // 1. Replace babel-loader with builtin:swc-loader for better performance. // 2. Remove Babel options and presets, specifically @babel/preset-typescript. // 3. Configure jsc.parser with syntax: 'typescript' and tsx: true. // 4. Maintain transform object with child objects runtime: 'automatic', and set development and refresh flags to !prod. // 5. set externalHelpers property to true // 6. Specify browser compatibility targets, such as Chrome >= 48. module.exports = { module: { rules: [{ test: [/\.tsx?$/i], use: [{ loader: 'babel-loader', options: { presets: ['@babel/preset-typescript'], }, }, ], }, ], }, }; ``` ### After ```ts module.exports = { module: { rules: [{ loader: 'builtin:swc-loader', options: { jsc: { parser: { syntax: 'typescript', tsx: true, }, externalHelpers: true, transform: { react: { runtime: 'automatic', development: !prod, refresh: !prod, }, }, }, env: { targets: 'Chrome >= 48', }, }, }, ], }, }; ```

To send a response from MSW handler, one would previously use something like `res(ctx.text("Hello world"))`. In msw v2, this is achieved by returning a native WebAPI Response object. msw v2 conveniently exposes a `HttpResponse` function that has useful methods for creating just that object with a desired body. This codemod replaces the old `res` calls with the new `HttpResponse` function calls and a bunch of ctx utilities that usually go with it. See examples below. This codemod does not remove unused properties on the callback signature due to the fact that there are more changes in other codemods included in the `upgrade-recipe` that rely on it. To apply these changes, you will have to run the recipe or run a `callback-signature` codemod that will do only that and replace all the references of old signature arguments. ## Before ```ts import { rest } from "msw"; rest.get("/user", (req, res, ctx) => { return res( ctx.json({ id: "abc-123" }), ctx.cookie("roses", "red"), ctx.cookie("violets", "blue"), ctx.set("X-Custom", "value"), ); }); ``` ## After ```ts import { rest } from "msw"; rest.get("/user", (req, res, ctx) => { return HttpResponse.json( { id: "abc-123" }, { headers: { "X-Custom": "value", "Set-Cookie": "roses=red;violets=blue;", }, }, ); }); ``` ## Before ```ts import { rest } from "msw"; rest.get("/user", (req, res, ctx) => { return res(ctx.text("Hello world!"), ctx.delay(500), ctx.status(401)); }); ``` ## After ```ts import { rest, delay } from "msw"; rest.get("/user", (req, res, ctx) => { await delay(500); return HttpResponse.text("Hello world", { status: 401, }); }); ``` ## Before ```ts import { rest } from "msw"; rest.get("/user", (req, res, ctx) => { return res(ctx.body("Hello world!"), ctx.set("Content-Type", "text/plain")); }); ``` ## After ```ts import { delay, rest } from "msw"; rest.get("/user", (req, res, ctx) => { return HttpResponse.text("Hello world"); }); ``` ## Before ```ts import { rest } from "msw"; rest.get("/user", (req, res, ctx) => { return res(ctx.text("Hello world!")); }); ``` ## After ```ts import { rest } from "msw"; rest.get("/user", (req, res, ctx) => { return HttpResponse.text("Hello world"); }); ``` ## Before ```ts graphql.query("GetUser", (req, res, ctx) => { return res( ctx.data({ user: { firstName: "John" }, }), ctx.errors([ { message: `Failed to login: user "${username}" does not exist` }, ]), ctx.extensions({ requestId: "abc-123", }), ); }); ``` ## After ```ts graphql.query('GetUser', (req, res, ctx) => { return HttpResponse.json( data: { user: { firstName: 'John' }, }, errors: [ { message: `Failed to login: user "${username}" does not exist` }, ], extensions: { requestId: 'abc-123', }, ) }) ```

Replace `IndexRoute` with `Route` having `exact` prop set to `true`.

This recipe is a set of codemods that will upgrade your project from using `mocha` to `vitest`. The recipe includes the following codemods: - [migrate-configuration](https://github.com/codemod-com/commons/tree/main/codemods/mocha/vitest/migrate-configuration) - [migrate-tests](https://github.com/codemod-com/commons/tree/main/codemods/mocha/vitest/migrate-tests) NOTE: if you are not using vitest default `.spec.*` or `.test.*` file names, then you won't be able to run your tests upon migrating. To mitigate this and add your own set of globs, create `vite.config.ts` file in the root of your project and add the following configuration, replacing `**/test/*.ts` with your own globs: ```ts import { configDefaults, defineConfig } from "vitest/config"; export default defineConfig({ test: { include: [...configDefaults.include, "**/test/*.ts"], }, }); ```

# 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.

# Add Cookie Path to All Methods This codemod adds `{ path: '/' }` to all `cookies` method calls in your TypeScript project. It ensures that cookies are set, deleted, or serialized with the correct path specified, which helps in consistent cookie handling across different environments. ## Transformations This codemod performs the following transformations: - **Set Cookie**: Transforms `cookies.set(key, value)` into `cookies.set(key, value, { path: '/' })`. - **Delete Cookie**: Transforms `cookies.delete(key)` into `cookies.delete(key, { path: '/' })`. - **Serialize Cookie**: Transforms `cookies.serialize(key, value)` into `cookies.serialize(key, value, { path: '/' })`. ## Usage To apply this codemod, run the workflow script on your TypeScript files. Ensure you have the necessary dependencies installed and your project is configured to use this codemod. ## Example ### Before ```typescript cookies.set('session', 'abc123'); cookies.delete('user'); cookies.serialize('token', 'xyz789'); ``` ### After ```ts cookies.set('session', 'abc123', { path: '/' }); cookies.delete('user', { path: '/' }); cookies.serialize('token', 'xyz789', { path: '/' }); ```

Update Fetch Requests to Handle Caching This codemod refactors fetch requests to handle caching according to new default behaviors. By default, fetch requests are no longer cached. Use the cache option to cache specific requests, or set fetchCache in a layout or page to control caching behavior globally. - Find Fetch Requests: Identifies fetch requests in the code that need caching adjustments. - Property Check: Ensures that fetch requests are updated with the cache option where needed and adds the fetchCache option to control global caching. - Add Caching Configuration: Adds export const fetchCache = 'default-cache' to layouts or pages to cache all requests by default unless overridden. ### Before ```js // app/layout.js export default async function RootLayout() { const a = await fetch("https://example.com/data"); // Not Cached const b = await fetch("https://example.com/another-data", { cache: "force-cache", }); // Cached // ... } ``` ### After ```js // app/layout.js // Since this is the root layout, all fetch requests in the app // that don't set their own cache option will be cached by default. export const fetchCache = "default-cache"; export default async function RootLayout() { const a = await fetch("https://example.com/data"); // Cached const b = await fetch("https://example.com/another-data", { cache: "no-store", }); // Not Cached // ... } ``` ### Explanation - Default Behavior Change: fetch requests are no longer cached by default. - Opt-in Caching: Use the cache: 'force-cache' option to cache individual fetch requests. - Global Caching Control: Use export const fetchCache = 'default-cache' in a layout or page to apply caching to all fetch requests that don't specify their own cache options.