hypermod-io / hypermod-community Goto Github PK

Is it possible to rename the binary name to match the module name? @codemod/cli

It will be more consistent and the docs will make more sense.

https://github.com/CodeshiftCommunity/CodeshiftCommunity/blob/d7a2ef0cf7cf8fc358020d52ad85a12adbda4c20/packages/cli/package.json#L10

If a user attempts to fetch a codemod without specifying the transform, present an interactive list of codemods for that package:

ie codeshift --packages @compiled/codemods path/to/foo

For users not publishing codemods to the community folder, we want to still provide a way for consumers to bundle + publish their codemods for use with our CLI.

Related thread: facebook/jscodeshift#126

This might look a little something like this:

@codeshift/cli publish path/to/transform

Dependency management might be an interesting challenge, but i think we can solve that by requiring transforms to also be accompanied by a codeshift.config.js file containing everything it needs.

Codemods should be shareable via normal npm packages.

This would mean that a package like react could create a codeshift.config.js and link transforms.

Codeshift cli will then pull the package and attempt to locate a config file. If that file is not found, it will attempt to pull a codemod from the community folder.

Uncomment this: https://github.com/CodeshiftCommunity/CodeshiftCommunity/blob/main/packages/cli/src/main.ts#L105

list command throws if one module is not found, it should log and continue listing the packages.

codeshift-cli list ffffff @altaskit/avatar @emotion/monorepo

We need to ensure all supported jscodeshift flags are accepted and passed through to jscodeshift

CLI errors are often output with stack traces and other data that makes the CLI look completely broken when an error is thrown. Ensure that these errors are presented nicely

Allow for packages outside of the community repo to be published with the CLI to an npm namespace / registry of the user's choice.

It will need to:

• Init ✅
• Validate ✅
• Build
• Version ??? (maybe)
• Publish

Community codemod packages have config files output to the dist folder. This directory is not searched by the fetcher so will not be able to locate the config.

https://unpkg.com/browse/@codeshift/[email protected]/

We should either:

• Move to a searched directory
• Add dist to a known directory
• Add package.json main to the known directories

Seems like dependencies are no longer being resolved

Examples command: npx @codeshift/cli --packages @atlaskit/[email protected] ../foo/bar/src

Output:

Cause:

This is likely due to the bundling, or with the resolution of dependencies via live-package-manager

The upgrade command would work similarly to the github bot.

• It will search your package.json for dependencies
• If any of those dependencies have a codemod that can be run respective to the current version
• Run the codemod and bump the package.json

facebook/jscodeshift#352

hey, the stuff you added in #58 is very exciting!

i think only problem is that the codeshift-cli package is not available on npm yet?

i would actually consider naming it codemods-cli - since end consumers of the library don't necessarily know what "codeshift" is, but do know what a "codemod" is - i think it'd be better understandable.

Take some inspo from the CRA home page.

https://create-react-app.dev/
http://testing-library.com/

Guidance like:

• Run yarn or npm install
• git init

from:

• https://www.codeshiftcommunity.com/docs/authoring

links to:

• https://www.codeshiftcommunity.com/docs/authoring/docs/contribution

when should link to:

• https://www.codeshiftcommunity.com/docs/contribution

tried fixing it but haven't used mdx before so dunno how, it didn't work, so just fyi.

We should add some interactive options in the case that information is missing on run.

IE if a transform isn't specified:

codeshift -p react

The cli should output an interactive list of codemods to run.

- v10.0.0
- v18.0.0
- ...

This could also be applied to other flags and sub commands like list

npx @codeshift/cli --packages @atlaskit/[email protected] .temp/src/Avatar.tsx

Running codeshift/cli via npx takes FAR too long to be worthwhile..

We need to investigate how to speed that up. Most likey, we'll need to cut down on bundlesize.

Existing registry sidebar:

Here are some ideas on how this might be improved:

• add a 'search' input to filter down the list (this will be helpful as the registry grows)
• Would it make sense to put packages in a @namespace in their own sections?
• Should namedspaced packages (eg @atlaskit/avatar) have the @ prefix?

codeshift.config.ts is intended to act as the source of truth for every codemod package. Configs serve a dual purpose of holding all relevant metadata and one or more codemods.

Config properties

• maintainers: Github maintainer usernames to be pinged when an issue/pr is raised against a mod
• description: Description of the package
• target: Packages to target. This will be used by the github bot to trigger codemod runs in the future
• transforms: Key-value pair of transforms organised by semver version. These are indented for package targeting
• presets: Generic transforms that are related to the package

Example:

export default {
  maintainers: ['danieldelcore'],
  description: "Codemods for upgrading @atlaskit/avatar",
  target: ["@atlaskit/avatar", "@atlaskit/avatar-group"],
  transforms: {
    // Transforms for migrating to v1 of atlaskit avatar
    "1.0.0": require("./1.0.0/transform"), 
    "2.0.0": require("./2.0.0/transform"), 
  },
  presets: {
    // Generic codemods intended to support the use of @atlaskit/avatar
    "remove-chilren-props": require("./remove-chilren-props/transform"),
  },
};

There are two types of codemods:

• transforms these are intended to move a package on NPM across versions. (v1->v2)
• presets intended to support the package (remove deprecated api)

Problems

• With the separation of versioned codemods, and presets is a bit odd. Ideally we can flatten this structure a bit more

Think of things like "Skip a test" or "Remove white space".

There are a lot of codemods that are written for general use.
Consider "sort imports", "convert to arrow function" etc

These should have a home in this repo too for people who might find them useful.

My suggestion is to provide a preset folder which behaves similarly to the community folder, but without the restrictions on file names etc.

at this point i'm reaching the boundaries of what can be done w/ this, without modifying the source code of jscodeshift itself.

it would be very benefitial to have a fork that we use directly.

i've done this a lot already - you fork the repository into your org, and add it here as a git submodule.
some build steps will need to be updated, but otherwise we'd be able to maintain our fork of jscodeshift, work out whatever behavior we want, and then even submit patches upstream (exactly what i'm doing now, but one level lower:D)

wdyt? myself need this a lot.

codeshift-cli init --package-name="codemods" ~/Development/codemods

Does not output codemod directory if neither a transform or preset are provided

codeshift-cli init --package-name="foobar"

Does not output a directory in the current dir.

https://github.com/CodeshiftCommunity/CodeshiftCommunity/blob/1a4a3cc09392be62d79b37116f9c63612e760361/packages/test-utils/src/apply-transform.ts#L9

facebook/jscodeshift#454

Allow for packages outside of the community repo to be validated with the CLI to ensure that they're able to be published in the expected format.

Codeshift should be extended to support modules that have APIs that span across JS and CSS.

The idea is that a library maintainer can ship an API change to their library that affects both JS and CSS. This codemod would then be configured to run a transform for both environments.

Unfortunately JSCodehsift + Recast aren't designed to do that, however we can substitute other parsers like PostCSS as options.

https://twitter.com/danieldelcore/status/1496718163714576386?s=20&t=v4nUru6h12nyrnt6M88TKA

A config could look something like this:

{
  module.exports = {
    transforms: {
    "10.0.0": {
      "js,jsx,tsx,ts": require.resolve("./10.0.0/transform")
      "css,sass,scss":  require.resolve("./10.0.0/transform/css")
     },
};

These extensions would be globs/regex that would match file extensions and apply a different codemod as a result.
These would be paired with custom parsers that would be "part" of the codeshift library.

import { FileInfo } from 'jscodeshift';
import postcss, { Node, Rule, Declaration, Plugin } from 'postcss';
import lessSyntax from 'postcss-less';

// https://github.com/postcss/postcss/blob/main/docs/writing-a-plugin.md
// https://astexplorer.net/#/2uBU1BLuJ1
const plugin = (): Plugin => {
  const processed = Symbol('processed');

  return {
    postcssPlugin: 'UsingTokens',
    Declaration: (decl) => {
      // @ts-expect-error
      if (decl[processed]) {
        return;
      }

      // Transformation goes here

      decl[processed] = true;
    },
  };
};

export default async function transformer(file: FileInfo) {
  return await postcss([plugin()]).process(file.source, { syntax: lessSyntax })
    .css;
}

facebook/jscodeshift#124

codeshift-cli init should output a helpful README.md with the codemod name and instructions about when to use it

it wasn't clear in the docs i think and i'm not sure what'd be best / what you follow so let me know.

Scanning npm for packages about codemods I have found codemod-cli:
https://www.npmjs.com/package/codemod-cli

It looks like a tool to create and manage collections of codemods. It takes care of:

• creating a new project, which includes a CLI to easily execute the codemods as a standalone CLI tool
• adding new codemods to the project, having an specific folder structure (that I find interesting)
• testing the codemods
• updating the documentation. Not sure how it does it, but I am pretty sure it picks the input and output fixtures to generate the examples

Maybe you should consider contacting the author and talk him about the codeshift community, or at least add it to the resources section?

I'm trying to write a codemod that changes from the old style of type imports:

import type {MyType} from './types';

to the newer style:

import {type MyType} from './types';

I saw you have some import helpers, but don't see anything that allows creation of an ImportSpecifier with importKind: "type", which I think is what is needed. Maybe you could consider adding it?

Thanks!

https://rajasegar.github.io/ast-builder/

Live-package-manager outputs codemods to current directory instead of in the directory in which the CLI source lives/execution.

For example finding the nearest CallExpression

function isDecendantOfToken(path: any) {
  if (!path.parentPath) {
    return false;
  }

  if (
    path.parentPath.value.type === 'CallExpression' &&
    path.parentPath.value.callee.name === 'token'
  ) {
    return true;
  }

  return path.parentPath;
}

Currently dependencies bundled with codemods are not accessible due to jscodeshift being unable to run codemods as functions.

We may need to fork jscodeshift or hack around it so that we can pass bundled codemods into it and fix our dependency issues.

For example, this command will break when run outside of the main repo: npx @codeshift/[email protected] --packages @atlaskit/[email protected] packages

For local development, we should list local codeshift.config transforms when no packages or transforms provided.

This would work by:

• Searching a few known locations for a codeshift.config
• Listing those options as an interactive selection list
• And running them

Make sure to also upgrade the default testing commands in the project template (ie codeshift init)

The init command should not require a version upfront. Instead that flag should be optional. If the version isn't specified, make sure a "commented" version of a config is output to give users a quick starting point.

It wasn't clear to me that the codemod registry was under the 'explore' tab (maybe it's just me!)

Here are some alternatives:

• 'Codemods'
• 'Registry'
• 'Codemod registry'

Allow for initialisation of new packages outside of the community repo with the CLI.

Outputting a clean and valid file structure / configuration that is ready to be published

Thanks a lot for creating this community, it is a great start to spread awareness about codemods and automated migration tools.
Being a codemod author brings joy to see these kind of initiatives from the community. Does it make sense to have a forum in Slack or Discord for the community to get help, discuss and build codemods or is it too early?

I leave the timelines to you folks since you are the best people to make the decisions. Thanks once again and would be glad to help in anyway possible.

JSCodeshift currently only provides a CLI API which is problematic for people who would like to build on top of it to provide, for example, a customised CLI with additional features etc (like what we're hoping to do with this project)

We should investigate either using import * as jscodeshift from 'jscodeshift/src/Runner'; or fork jscodeshift to and mould it into something more official.

Related issues:

• facebook/jscodeshift#179
• facebook/jscodeshift#398