`: Resulting file after transform has been applied
+
+**Example**
+
+```jsx
+import * as transformer from '../transform';
+import { applyTransform } from '@hypermod/utils';
+
+it('should wrap avatar in a tooltip if name is defined', async () => {
+ const result = await applyTransform(
+ transformer,
+ `
+ import Avatar from 'avatar';
+
+ const App = () => {
+ return ;
+ }
+ `,
+ { parser: 'tsx' },
+ );
+
+ expect(result).toMatchInlineSnapshot(`
+ "import Tooltip from 'tooltip';
+ import Avatar from 'avatar';
+
+ const App = () => {
+ return ;
+ }"
+ `);
+});
+```
diff --git a/website/docs/authoring.mdx b/website/docs/authoring.mdx
index 952a520d6..ed47ea2e7 100644
--- a/website/docs/authoring.mdx
+++ b/website/docs/authoring.mdx
@@ -16,7 +16,7 @@ Which one to use depends on your particular use case.
## 1. Contribute to the public registry
-The public registry is the public directory of codemods hosted and published directly from this repository, [visible here](https://github.com/CodeshiftCommunity/CodeshiftCommunity/tree/main/community).
+The public registry is the public directory of codemods hosted and published directly from this repository, [visible here](https://github.com/hypermod-io/hypermod-community/tree/main/community).
This directory can be compared to and treated the same as the Typescript type definition registry: [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped).
_Please see the [Contribution guide](contribution) for more information._
diff --git a/website/docs/consuming.mdx b/website/docs/consuming.mdx
index e2346a06b..a95450b1c 100644
--- a/website/docs/consuming.mdx
+++ b/website/docs/consuming.mdx
@@ -7,18 +7,18 @@ keywords:
[codemod, consuming, refactor, codebase, development workflow, command line]
---
-Running codemods is made simple through our CLI tool, [@codeshift/cli](/docs/cli).
+Running codemods is made simple through our CLI tool, [@hypermod/cli](/docs/cli).
-> @codeshift/cli is responsible for running the provided transform against your entire codebase. Under the hood, it is a wrapper of jscodeshift's cli, which provides additional functionality
+> @hypermod/cli is responsible for running the provided transform against your entire codebase. Under the hood, it is a wrapper of jscodeshift's cli, which provides additional functionality
-For usage please refer to the [@codeshift/cli API reference](/docs/cli).
+For usage please refer to the [@hypermod/cli API reference](/docs/cli).
## How to run Community codemods
-To run a codeshift package, install and use the `@codeshift/cli`.
+To run a hypermod package, install and use the `@hypermod/cli`.
-- **npm:** `npm install -g @codeshift/cli` or
-- **yarn:** `yarn global add @codeshift/cli`
+- **npm:** `npm install -g @hypermod/cli` or
+- **yarn:** `yarn global add @hypermod/cli`
For example, say we want to run transforms for `@mylib/button` and migrate from version 13 to the latest version 14, we could run the following:
@@ -28,9 +28,9 @@ codemod-cli --packages @mylib/button@14.0.0 project/path/to/src
The following sequence of events will follow:
-1. `@codeshift/cli` will then attempt to download a codeshift package for the `@mylib/button` package matching version `14.0.0`
+1. `@hypermod/cli` will then attempt to download a Hypermod package for the `@mylib/button` package matching version `14.0.0`
1. Download the package from NPM
-1. Locate the `codeshift.config.js`
+1. Locate the `hypermod.config.js`
1. Attempt to find a `transform` for `14.0.0`
1. Run the transform against the path `project/path/to/src`
@@ -38,7 +38,7 @@ The following sequence of events will follow:
It's also possible to run a series of codemods, one after the other, to migrate your usage of `@mylib/button` across multiple major versions, from say v14, v15 and finally v16. Assuming codemods for those versions exist.
-This is done my providing the `--sequence` (or `-s`) flag to `@codeshift/cli`.
+This is done my providing the `--sequence` (or `-s`) flag to `@hypermod/cli`.
```
codemod-cli --packages @mylib/button@14.0.0 --sequence project/path/to/src
@@ -57,8 +57,8 @@ codemod-cli --transform path/to/transform.ts project/path/to/src
## Parsing TypeScript & Flow
-By default `@codeshift/cli` will use `babel` as the default parser and only transform files with a `.js` extensions.
+By default `@hypermod/cli` will use `babel` as the default parser and only transform files with a `.js` extensions.
If your repo depends on flow or typescript, it's important to remember to specify `ts`, `tsx` or `flow` as the `--parser` and or `jsx, ts, tsx` as `--extensions` to make sure jscodeshift can interpret the files properly.
-Please refer to the [@codeshift/cli API reference](/docs/cli) for more information.
+Please refer to the [@hypermod/cli API reference](/docs/cli) for more information.
diff --git a/website/docs/contribution.mdx b/website/docs/contribution.mdx
index 2678d4341..db8f10af4 100644
--- a/website/docs/contribution.mdx
+++ b/website/docs/contribution.mdx
@@ -8,7 +8,7 @@ keywords: [codemod, contribution, authoring, publishing, tips, best practices]
This page covers the process of authoring and publishing codemods, including tips and best practices for creating high-quality codemods that others can use and benefit from.
-It is intended to explain in detail contribution to [the public registry](https://github.com/CodeshiftCommunity/CodeshiftCommunity/tree/main/community) and is for authors who want:
+It is intended to explain in detail contribution to [the public registry](https://github.com/hypermod-io/hypermod-community/tree/main/community) and is for authors who want:
- Codemods to be open source
- Build tooling, dependency management and project setup to be handled for you
@@ -55,7 +55,7 @@ Transformers are the main entrypoint to your codemod, they are responsible for a
**Example:**
```ts
-import { hasImportDeclaration } from '@codeshift/utils';
+import { hasImportDeclaration } from '@hypermod/utils';
export default function transformer(file, { jscodeshift: j }, options) {
const source = j(file.source);
diff --git a/website/docs/external-packages.mdx b/website/docs/external-packages.mdx
index 5ad4e54e8..02deec866 100644
--- a/website/docs/external-packages.mdx
+++ b/website/docs/external-packages.mdx
@@ -8,7 +8,7 @@ keywords: [codeshift, package, creation, npm, tips, best practices]
This page covers creation of stand-alone codeshift packages and is for authors who want:
-- Control over where and how your codeshift package is hosted
+- Control over where and how your Hypermod package is hosted
- Control over tooling, dependencies and techstack
- The option to create completely generic codemods that don't target specific packages
@@ -16,28 +16,28 @@ If you prefer to not to maintain a separate package, please see the [Authoring g
## Initializing
-To create a standalone codeshift package automatically, install the install and use the `codeshift/cli`.
+To create a standalone Hypermod package automatically, install the install and use the `hypermod/cli`.
-- **npm:** `npm install -g @codeshift/cli` or
-- **yarn:** `yarn global add @codeshift/cli`
+- **npm:** `npm install -g @hypermod/cli` or
+- **yarn:** `yarn global add @hypermod/cli`
Then given you want to initialize a new project called "foobar", with a codemod targeting version `10.0.0` you can run the following command:
-`$ codeshift init --package-name="foobar" --version="10.0.0" ~/Desktop`
+`$ hypermod init --package-name="foobar" --version="10.0.0" ~/Desktop`
This will create a new directory called "foobar" in the `~/Desktop` directory.
You can then also initialize subsequent transforms and presets by running the command again:
-`$ codeshift init --package-name="foobar" --preset="sort-imports" ~/Desktop`
+`$ hypermod init --package-name="foobar" --preset="sort-imports" ~/Desktop`
### File structure
-The file structure of your new codeshift package will look like this:
+The file structure of your new hypermod package will look like this:
```
react-cool-library/
- codeshift.config.js // main entrypoint containing configuration and references to your transforms
+ hypermod.config.js // main entrypoint containing configuration and references to your transforms
package.json
tsconfig.json
jest.config.js
@@ -56,9 +56,9 @@ See the [Testing guide](testing) for help getting started with unit tests.
## Publishing
-Since your new codeshift package can simply be treated as an NPM package you can simply run `npm version [patch\minor\major]` and `npm publish`.
+Since your new hypermod package can simply be treated as an NPM package you can simply run `npm version [patch\minor\major]` and `npm publish`.
-Your package will now be accessible via the `codeshift/cli`. Refer to the [Consuming guide](consuming) for information about how to run your new codemods.
+Your package will now be accessible via the `hypermod/cli`. Refer to the [Consuming guide](consuming) for information about how to run your new codemods.
## Examples
diff --git a/website/docs/guides/css-codemods.mdx b/website/docs/guides/css-codemods.mdx
index 8f26fd87d..4f1b208ee 100644
--- a/website/docs/guides/css-codemods.mdx
+++ b/website/docs/guides/css-codemods.mdx
@@ -20,9 +20,9 @@ As an example, We'll take the JS/CSS use-case and use the popular [PostCSS](http
## Step 1: Installing dependencies
-Get started by creating a new Codeshift package with `npx @codeshift/cli init --package-name css-codemod --preset update-css-api .`.
+Get started by creating a new Hypermod package with `npx @hypermod/cli init --package-name css-codemod --preset update-css-api .`.
-This will create a new Codeshift package with a configuration file and empty transform file for the preset you specified.
+This will create a new Hypermod package with a configuration file and empty transform file for the preset you specified.
Navigate into your new directory with `cd css-codemod` and install the relevant dependencies: `npm install -s postcss`
@@ -108,5 +108,5 @@ const plugin = (): Plugin => {
You've created your very first CSS codemod, nice work! We can now run it against some code to verify that's it's working correctly.
```
-npx @codeshift/cli -t css-codemod/src/update-css-api.ts -e css path/to/src
+npx @hypermod/cli -t css-codemod/src/update-css-api.ts -e css path/to/src
```
diff --git a/website/docs/guides/monorepos.mdx b/website/docs/guides/monorepos.mdx
index d28b9f41d..a0a4a681d 100644
--- a/website/docs/guides/monorepos.mdx
+++ b/website/docs/guides/monorepos.mdx
@@ -2,15 +2,15 @@
id: monorepos
title: Integrating with monorepos
slug: /monorepos
-description: Learn about monorepos and how they can be used with codeshift. This page covers the benefits of using a monorepo for your codebase, including improved organization, collaboration, and scalability. We'll also discuss how to use codeshift to automatically refactor code in a monorepo and the best practices for working with monorepos and codemods.
+description: Learn about monorepos and how they can be used with Hypermod. This page covers the benefits of using a monorepo for your codebase, including improved organization, collaboration, and scalability. We'll also discuss how to use hypermod to automatically refactor code in a monorepo and the best practices for working with monorepos and codemods.
keywords: [monorepos, workspaces, lerna, yarn, scalability, packages]
---
-Codeshift is specifically designed to play nicely with monorepos (AKA multi-package repositories, multi-project repositories, or monolithic repositories) such as [Turborepo](https://turborepo.org/), [Yarn](https://classic.yarnpkg.com/lang/en/docs/workspaces/), [npm](https://docs.npmjs.com/cli/v7/using-npm/workspaces/) and [pnpm](https://pnpm.io/workspaces) workspaces and [Lerna](https://lerna.js.org/).
+Hypermod is specifically designed to play nicely with monorepos (AKA multi-package repositories, multi-project repositories, or monolithic repositories) such as [Turborepo](https://turborepo.org/), [Yarn](https://classic.yarnpkg.com/lang/en/docs/workspaces/), [npm](https://docs.npmjs.com/cli/v7/using-npm/workspaces/) and [pnpm](https://pnpm.io/workspaces) workspaces and [Lerna](https://lerna.js.org/).
## Configuration
-Configuring Codeshift in a monorepo can be done in the exact same way as [any existing npm package](/docs/authoring#2-add-codeshift-to-an-existing-package), simply by adding `codeshift.config.js` files and codemods to your packages.
+Configuring Hypermod in a monorepo can be done in the exact same way as [any existing npm package](/docs/authoring#2-add-hypermod-to-an-existing-package), simply by adding `hypermod.config.js` files and codemods to your packages.
Given you are using a workspace-based monorepo, it's recommended to co-locate codemods with your package source files so they can be published as part of the package, for use by both external and internal users.
@@ -22,7 +22,7 @@ packages/
+ transform.ts
+ transform.spec.ts
+ 2.0.0/
-+ codeshift.config.js
++ hypermod.config.js
src/
...
package.json
@@ -34,7 +34,7 @@ packages/
package.json
```
-Codeshift config files can be located in either the root, `/src` or `/codemods` directory of a package.
+Hypermod config files can be located in either the root, `/src` or `/codemods` directory of a package.
```diff
packages/
@@ -47,7 +47,7 @@ packages/
package.json
rollup.config.json
jest.config.js
-+ codeshift.config.js
++ hypermod.config.js
dialog/
modal/
@@ -61,12 +61,12 @@ See the [configuration guide](/docs/configuration) for help writing config files
## Initializing
-Codeshift provides a CLI to quickly codegen a working codemod package around your existing source files. To do so, run `init` with the `--config-only` flag,
+Hypermod provides a CLI to quickly codegen a working codemod package around your existing source files. To do so, run `init` with the `--config-only` flag,
which will output a bare-bones configuration. If you provide a `--transform` or `--preset` it will also generate empty transform files in addition.
-`$ codeshift init --config-only --transform 10.0.0 --preset foobar packages/my-package`
+`$ hypermod init --config-only --transform 10.0.0 --preset foobar packages/my-package`
-(Note: this script assumes you have installed `@codeshift/cli` globally)
+(Note: this script assumes you have installed `@hypermod/cli` globally)
The output of this command will give you a filestructure matching the above example.
@@ -76,7 +76,7 @@ When writing codemod(s) it's recommended to use a [test-driven development appro
Once you're confident that your codemod works as expected, you will likely want to manually verify against real code.
That's where you can use the following command:
-`$ codeshift path/to/test/code`.
+`$ hypermod path/to/test/code`.
When used at the root directory of your monorepo, the CLI will leverage your workspaces config located in your `package.json` to determine which codemods in the monorepo it can run.
@@ -95,7 +95,7 @@ And show an interactive list for you to search and can choose from.
## Publishing
The workflow to publishing your codemod enhanced packages should remain completely unchanged.
-However, it's important to verify that your `codeshift.config.js` and codemods are not ignored by npm (via `.npmignore` or similar) so that they are successfully published to the registry.
+However, it's important to verify that your `hypermod.config.js` and codemods are not ignored by npm (via `.npmignore` or similar) so that they are successfully published to the registry.
In some cases you may need to add these to the `files` property of your package's `package.json` like so:
@@ -104,19 +104,19 @@ In some cases you may need to add these to the `files` property of your package'
"name": "@monorepo/my-package",
"version": "0.6.0",
"main": "./dist/index.js",
- "files": ["dist", "src", "codemods", "codeshift.config.js"]
+ "files": ["dist", "src", "codemods", "hypermod.config.js"]
}
```
## Running
-Running a codemod as a consumer can now be done via the `@codeshift/cli`, assuming your package is named `@monorepo/my-package` and your codemod is `1.0.0`:
+Running a codemod as a consumer can now be done via the `@hypermod/cli`, assuming your package is named `@monorepo/my-package` and your codemod is `1.0.0`:
-`$ codeshift --packages @monorepo/my-package@1.0.0 /path/to/source`
+`$ hypermod --packages @monorepo/my-package@1.0.0 /path/to/source`
You can even omit the codemod name to be prompted with all codemods as an interactive list:
-`$ codeshift --packages @monorepo/my-package /path/to/source`
+`$ hypermod --packages @monorepo/my-package /path/to/source`
## Examples
diff --git a/website/docs/introduction.mdx b/website/docs/introduction.mdx
index 4f9eceda1..82edc4d06 100644
--- a/website/docs/introduction.mdx
+++ b/website/docs/introduction.mdx
@@ -2,7 +2,7 @@
id: introduction
title: Introduction
slug: /
-description: 'Welcome to the codeshiftcommunity. This is a community of developers who use codeshift to automatically refactor their codebase. Join us to learn more about codeshift, share your own codemods, and collaborate with others.'
+description: 'Welcome to the codeshiftcommunity. This is a community of developers who use Hypermod to automatically refactor their codebase. Join us to learn more about Hypermod, share your own codemods, and collaborate with others.'
keywords: [codeshift, getting started, best practices]
---
@@ -36,7 +36,7 @@ To accomplish this, CodeshiftCommunity aims to address three key challenges:
### Fragmentation in the ecosystem
-CodeshiftCommunity offers a platform-agnostic toolchain for creating, publishing, and using codemods, centered around the @codeshift/cli. This CLI provides common infrastructure and eliminates the need for developers to constantly recreate the same tools.
+CodeshiftCommunity offers a platform-agnostic toolchain for creating, publishing, and using codemods, centered around the @hypermod/cli. This CLI provides common infrastructure and eliminates the need for developers to constantly recreate the same tools.
Some popular libraries in the ecosystem, such as [React](https://github.com/reactjs/react-codemod), [material-ui](https://github.com/mui-org/material-ui/tree/master/packages/material-ui-codemod) and [next.js](https://nextjs.org/docs/advanced-features/codemods), all offer their own solutions for codemods, CLI, and distribution services. These services are inconsistent and often difficult for the average user to access. While providing these services can be helpful for upgrading libraries, it also places a significant burden on the projects that offer them.
@@ -52,7 +52,7 @@ Writing a changelog and constantly answering the same questions about how to mig
### Lack of documentation & familiarity
-Writing codemods can often feel like a specialized skill that only a few people in a company know how to do. CodeshiftCommunity aims to change this by providing a hub for documentation and guidance.
+Writing codemods can often feel like a specialized skill that only a few people in a company know how to do. Hypermod aims to change this by providing a hub for documentation and guidance.
By offering guides, recipes, and reference materials, we hope to demystify codemods and make them more accessible to everyone. With the right documentation in place, it will be easier to normalize the use of codemods and reduce their learning curve.
@@ -76,7 +76,7 @@ By using NPM, we aim to make it easy for developers to adopt codemods. All they
Our goal is to achieve broad coverage of common JS dependencies, such as React, Jest, and Chalk, by collaborating with the wider JS community to produce high-quality, versioned codemods.
-CodeshiftCommunity offers a registry that hosts and automatically publishes codemods under the [/community directory](https://github.com/CodeshiftCommunity/CodeshiftCommunity/tree/main/community). This directory organizes codemods by package name and version, and publishes them to npm as modules that can be updated or improved. This ensures that users who run codemods always have access to the latest version.
+CodeshiftCommunity offers a registry that hosts and automatically publishes codemods under the [/community directory](https://github.com/hypermod-io/hypermod-community/tree/main/community). This directory organizes codemods by package name and version, and publishes them to npm as modules that can be updated or improved. This ensures that users who run codemods always have access to the latest version.
### Rich documentation
diff --git a/website/docs/motions.mdx b/website/docs/motions.mdx
index 337648033..d7036a311 100644
--- a/website/docs/motions.mdx
+++ b/website/docs/motions.mdx
@@ -19,7 +19,7 @@ function removeDeprecatedProps(j, source) {
Motions can then be applied from the main transform, just like any other function.
```ts
-import { hasImportDeclaration } from '@codeshift/utils';
+import { hasImportDeclaration } from '@hypermod/utils';
import removeDeprecatedProps from './motions/remove-deprecated-props';
import restructureImports from './motions/restructure-imports';
@@ -39,7 +39,7 @@ Each motion receives a reference to the AST (`source`) which it can then manipul
Alternatively, you can use the utility function [applyMotions](./utils#applymotionsj-source-motions) to run motions in sequence.
```ts
-import { applyMotions } from '@codeshift/utils';
+import { applyMotions } from '@hypermod/utils';
import removeDeprecatedProps from './motions/remove-deprecated-props';
import restructureImports from './motions/restructure-imports';
diff --git a/website/docs/recipes/import-manipulation.mdx b/website/docs/recipes/import-manipulation.mdx
index f5425944d..ea288fabb 100644
--- a/website/docs/recipes/import-manipulation.mdx
+++ b/website/docs/recipes/import-manipulation.mdx
@@ -29,7 +29,7 @@ The anatomy of an `ImportDeclaration` includes:
- `ImportSpecifier`: `useEffect`
- A `source` which can either be a module name or path: `react`
-**Note: `@codeshift/utils` provides utilities for import manipulation, please see the docs**
+**Note: `@hypermod/utils` provides utilities for import manipulation, please see the docs**
### Finding an import declaration
@@ -196,17 +196,18 @@ export default function transformer(file, { jscodeshift: j }, options) {
.find(j.ImportDeclaration) // Find all nodes that match a type of `ImportDeclaration`
.filter(path => path.node.source.value === 'react'); // Filter imports by source equal to the target ie "react"
- reactImports.forEach((
- reactImport, // Iterate over react imports
- ) =>
- // Replace the existing node with a new one
- j(reactImport).replaceWith(
- // Build a new import declaration node based on the existing one
- j.importDeclaration(
- reactImport.node.specifiers, // copy over the existing import specificers
- j.stringLiteral('hot-new-library'), // Replace the source with our new source
+ reactImports.forEach(
+ (
+ reactImport, // Iterate over react imports
+ ) =>
+ // Replace the existing node with a new one
+ j(reactImport).replaceWith(
+ // Build a new import declaration node based on the existing one
+ j.importDeclaration(
+ reactImport.node.specifiers, // copy over the existing import specificers
+ j.stringLiteral('hot-new-library'), // Replace the source with our new source
+ ),
),
- ),
);
return source.toSource();
diff --git a/website/docs/recipes/react.mdx b/website/docs/recipes/react.mdx
index 00a8b829f..f91df487f 100644
--- a/website/docs/recipes/react.mdx
+++ b/website/docs/recipes/react.mdx
@@ -92,7 +92,10 @@ export default function transformer(file, { jscodeshift: j }, options) {
element.node.openingElement.attributes = [
...element.node.openingElement.attributes,
// build and insert our new prop
- j.jsxAttribute(j.jsxIdentifier('className'), j.stringLiteral('helloWorld')),
+ j.jsxAttribute(
+ j.jsxIdentifier('className'),
+ j.stringLiteral('helloWorld'),
+ ),
];
});
@@ -339,8 +342,6 @@ const Button = () => {
## JSX
-
-
### Wrapping components
Wrapping react components with react components is a fairly common operation.
@@ -473,7 +474,7 @@ This might seem difficult on the surface, but think about it like every other co
**Transform:**
```javascript
-import { getJSXAttributes } from '@codeshift/utils';
+import { getJSXAttributes } from '@hypermod/utils';
export default function transformer(file, { jscodeshift: j }, options) {
const source = j(file.source);
diff --git a/website/docs/registry.mdx b/website/docs/registry.mdx
index 73d53f720..af35136bc 100644
--- a/website/docs/registry.mdx
+++ b/website/docs/registry.mdx
@@ -17,7 +17,7 @@ keywords:
Welcome to the CodeshiftCommunity Public Registry. This is a collection of high-quality codemods that have been contributed by members of the community.
Browse our registry to find codemods that can help you automatically refactor your codebase, or contribute your own codemods to share with the community.
-Source for these packages can be found in the [/community folder](https://github.com/CodeshiftCommunity/CodeshiftCommunity/tree/main/community).
+Source for these packages can be found in the [/community folder](https://github.com/hypermod-io/hypermod-community/tree/main/community).
## Contribution
@@ -27,10 +27,10 @@ For other publishing options, including private and external codemod packages, p
## Running registry codemods
-Codemods from the registry can be run via the Codeshift CLI, for example:
+Codemods from the registry can be run via the Hypermod CLI, for example:
```
-$ npx @codeshift/cli --packages @atlaskit/button /project/src
+$ npx @hypermod/cli --packages @atlaskit/button /project/src
```
See the [CLI reference](/docs/cli) for more information.
diff --git a/website/docs/testing.mdx b/website/docs/testing.mdx
index a3bc285a0..7e4154be2 100644
--- a/website/docs/testing.mdx
+++ b/website/docs/testing.mdx
@@ -20,7 +20,7 @@ We'll also discuss best practices for writing effective tests that can help you
It's very likely that consumers will run into all sorts of edge-cases when running your codemod. That's why it's important to always start by writing tests (TDD style) to assert its behavior.
Think about a start and end state. How you might be able to achieve that? What edge-cases can potentially arise?
-CodeshiftCommunity (and [jscodeshift](https://github.com/facebook/jscodeshift#unit-testing)) exposes [testing utilities](/docs/test-utils) to help.
+CodeshiftCommunity (and [jscodeshift](https://github.com/facebook/jscodeshift#unit-testing)) exposes [testing utilities](/docs/utils) to help.
> Codemods are a textbook example of where TDD works. You have an input file, you run the script and you get output. Thus I would really recommend using TDD for codemod projects.
> Not only does it make codemods more stable, but having projects with test workflow setup, will help you learn.
@@ -30,7 +30,7 @@ CodeshiftCommunity (and [jscodeshift](https://github.com/facebook/jscodeshift#un
## Folder structure
-If you're planning to publish a codemod to [the public registry](https://github.com/CodeshiftCommunity/CodeshiftCommunity/tree/main/community), follow the [Authoring guide](/docs/authoring#initializing).
+If you're planning to publish a codemod to [the public registry](https://github.com/hypermod-io/hypermod-community/tree/main/community), follow the [Authoring guide](/docs/authoring#initializing).
Once you've initialized, your file structure should look something like this:
@@ -43,11 +43,12 @@ community/[package-name]/[version]
## An example
To give an example, consider you're trying to write a codemod that removes deprecated props from a component.
-In this case, you would be able to write a simple test using `jest` & `@codeshift/test-utils` like so..
+In this case, you would be able to write a simple test using `jest` & `@hypermod/utils` like so..
```jsx
+import { applyTransform } from '@hypermod/utils';
+
import * as transformer from '../transform';
-import { applyTransform } from '@codeshift/test-utils';
it('should remove all deleted props', async () => {
const result = await applyTransform(
diff --git a/website/docusaurus.config.js b/website/docusaurus.config.js
index bf9fb833f..de9b31465 100644
--- a/website/docusaurus.config.js
+++ b/website/docusaurus.config.js
@@ -64,7 +64,7 @@ module.exports = {
position: 'right',
},
{
- href: 'https://github.com/CodeshiftCommunity/CodeshiftCommunity',
+ href: 'https://github.com/hypermod-io/hypermod-community',
label: 'GitHub',
position: 'right',
},
@@ -111,7 +111,7 @@ module.exports = {
},
{
label: 'Discussions',
- href: 'https://github.com/CodeshiftCommunity/CodeshiftCommunity/discussions',
+ href: 'https://github.com/hypermod-io/hypermod-community/discussions',
},
{
label: 'Stack Overflow',
@@ -128,11 +128,11 @@ module.exports = {
items: [
{
label: 'GitHub',
- href: 'https://github.com/CodeshiftCommunity/CodeshiftCommunity',
+ href: 'https://github.com/hypermod-io/hypermod-community',
},
{
label: 'Roadmap',
- href: 'https://github.com/CodeshiftCommunity/CodeshiftCommunity/projects/1',
+ href: 'https://github.com/hypermod-io/hypermod-community/projects/1',
},
],
},
@@ -147,7 +147,7 @@ module.exports = {
docs: {
sidebarPath: require.resolve('./sidebars.js'),
editUrl:
- 'https://github.com/CodeshiftCommunity/CodeshiftCommunity/edit/main/website/',
+ 'https://github.com/hypermod-io/hypermod-community/edit/main/website/',
},
theme: {
customCss: require.resolve('./src/css/custom.css'),
diff --git a/website/sidebars.js b/website/sidebars.js
index 75b775ded..109ee9ba2 100644
--- a/website/sidebars.js
+++ b/website/sidebars.js
@@ -56,7 +56,7 @@ module.exports = {
type: 'category',
collapsible: false,
collapsed: false,
- items: ['api/cli', 'api/utils', 'api/test-utils'],
+ items: ['api/cli', 'api/utils'],
},
],
registry: [
diff --git a/website/src/pages/index.js b/website/src/pages/index.js
index bd7003795..77c69da53 100644
--- a/website/src/pages/index.js
+++ b/website/src/pages/index.js
@@ -207,13 +207,13 @@ const App = () => (
1. Initialize your project
- Instantly create a brand new codeshift package that can be
+ Instantly create a brand new Hypermod package that can be
run from anywhere.
- $ npx @codeshift/cli init foobar
+ $ npx @hypermod/cli init foobar
@@ -266,7 +266,7 @@ const App = () => (
{`import {
hasImportDeclaration,
renameImportDeclaration,
-} from '@codeshift/utils';
+} from '@hypermod/utils';
function transformer(file, { jscodeshift: j }) {
const source = j(file.source);
@@ -317,7 +317,7 @@ export default transformer;`}
- $ npx @codeshift/cli -p foobar@12.0.0 path/to/src
+ $ npx @hypermod/cli -p foobar@12.0.0 path/to/src
+