Comments (11)
I was about to propose something similar, so I'm glad someone else is also asking for it.
on your exampe I guess you mean this?
@codeshift/cli [email protected] path/to/transform/*.js
It will be nice, if each package doesn't need to be a single transform but a collection of transforms. It is a bit cumbersome to ask devs to publish a separate package for each codemod they want to share.
If you accept "collections" of codemods, some options to select an specific trasform may be:
@codeshift/cli [email protected]#transform-name path/to/transform/*.js
- Provide a list of the available codemods on that package and make the user pick one
This will also take advantage of the codeshift .config.file
from hypermod-community.
Hey @danielo515, thanks for chiming in!
Just so I can have more context, what kind of codemods / collections of codemods would you consider publishing?
Are they codemods intended for a specific package? For example codemods that migrate an npm package from one version to another? Or generic codemods that do things like order imports, change formatting etc?
Accept "collections" of codemods
Really interesting idea! Currently, we have the concept of "motions" that are essentially parts of a single codemod. An example of a motion could be,update imports
,remove props
,clean up file
. Authoring#motions . That might suit your use-case, otherwise maybe we can adapt that idea a bit.
It is a bit cumbersome to ask devs to publish a separate package for each codemod they want to share
For this we've created an init
command that auto generates a folders for each of the codemods you want to publish. Should speed things up a bit if you're interested
from hypermod-community.
Hello.
I am thinking more like generic or thematic collection of code mods. Right now there are two usual ways people share codemods
- very uncomfortably by asking you to clone their repository and giving the full path to codeshift
- they wrap jscodeshift cli themselves and ask you to run using "npx"
The first one is very tedious for the user, while the second one is wasteful and redundant, not to mention how confusing can be for end users.
Some examples of this last method are:
- react codemods
- lit codemods
- this same community cli
- my own personal codemods 😉
I really wish to see this cli become an standard way to run any codemod like npx is the standard way to run cli tools from npm.
That's why I mention that having just one codemod per package, albeit simpler to implement, it's not comfortable.
I have experience with lerna and other tools, but I still prefer to not have to have 10 packages published for a bunch of codemods
from hypermod-community.
I still prefer to not have to have 10 packages published for a bunch of codemods
Yeah that's totally fair, thanks for sharing!
So far, codemods related to a specific npm package like @atlaskit/avatar
are contained in their own package, organised by version since all of the codemods can be batched and run with the cli from the one package.
What i'd like to build next is a pretty much what you've described to a tee (I'm really glad you brought it up)!
Generic or thematic collection of code mods
My current thinking is to allow people to create preset
codemods that are generic in that they don't relate to a specific published npm package like react
or @atlaskit/avatar
but are more utility oriented.
To give an example, you might have a set of codemods that do things like sort-imports
, remove-default-import
, rename-relative-imports
, etc. These are generic in that they can be applied to any project.
The folder structure in my head right now is (Totally open to feedback here!):
/community
/@preset-import-management
/__tests__
/sort-imports.ts
/remove-default.ts
/rename-relative-imports.ts
/@preset-react
/class-to-function-component.ts
/remove-legacy-context.ts
/use-shorthand-fragments.ts
And that would be accessible via CLI in the same way you've described.
npx @codeshift/cli --preset import-management#sort-imports path/to/src
What do you think about that? Would that work for you?
Just out of interest what types of codemods would you like to publish? Would love to work with you on that to get them in 😄
from hypermod-community.
My current thinking is to allow people to create
preset
codemods that are generic in that they don't relate to a specific published npm package likereact
or@atlaskit/avatar
but are more utility oriented.
While the semantics may differ, I don't see technical differences other than, maybe, being tied to an specific library version. But the version it is just one more level of grouping, so it still kind of similar.
To give an example, you might have a set of codemods that do things like sort-imports, remove-default-import, rename-relative-imports, etc. These are generic in that they can be applied to any project.
Yeah, that is exactly what I am referring to
The folder structure in my head right now is (Totally open to feedback here!):
That folder structure looks reasonable for packages/transforms that live inside this repository. But some people may not want/can go to the hurdle of contribute to an open-source project just to share a bunch of codemods they have written. Or maybe those codemods doesn't fit into a generic community project.
Those kind of codemods may benefit from this cli accepting external packages.
So, similarly to the syntax you proposed can be done like this:
npx @codeshift/cli --package @danielo515/codemods#sort-imports path/to/src
If you want to take a look at the kind of stuff I'm talking about, here you have my personal codemods:
https://github.com/danielo515/codemods
Regards
from hypermod-community.
Ah cool, how would you expect this to work?
Because for security reasons, codemods would have to be published to the user's own NPM (ie people wouldn't be able to publish straight to this registry), which would require them to run some sort of publish command on their end, specify a package name to publish with etc. We could potentially do that, but might be fiddly for the user to set-up 🤔
so could look something like:
File structure
codemods/
/sort-imports.ts
codeshift.config.js
Configuration (codeshift.config.js)
{
name: 'mycodemods',
transforms: {
sortImports: require('./sort-imports.js');
}
}
Publish command
@codeshift/cli publish codemods/codeshift.config.js --someNPMToken 1111111
Consuming
@codeshift/cli --package mycodemods#sortImports /path/to/code
from hypermod-community.
Hello @danieldelcore
Everything you said makes sense except the publishing part. What do you mean by "publishing straight to this registry" ?
My proposition is to use public npm packages that people have, of course, published to npm
So the steps would be:
- Create a package following the conventions you mentioned (for ease of use, the
main
property of package.json should point tocodeshift.config.js
- Publish it to npm
npm publish
- You can use codeshift/cli to consume such package like on the last command you mentioned
- Codeshift will install the package locally, probably to a
.codeshift
configuration folder - codeshift will "require" the package and run the requested transformation
Think about like the plugin system babel uses, where anyone can publish a babel package as long as they stick to the babel conventions.
Let me know if this makes sense
from hypermod-community.
Ahh that clears it up for me thanks!
Well in that case, I see no reason why we couldn't do that!!
Your list is the plan moving forward! I'll follow up with the changes required!
from hypermod-community.
Your list is the plan moving forward!
Do you mean the steps I outlined?
from hypermod-community.
Yeah haha! I was overthinking it!
from hypermod-community.
Closing this issue for now, this should now be available via codeshift-cli init
+ npm run build
+ npm publish
from hypermod-community.
Related Issues (20)
- 🙏 The codemod wishlist HOT 1
- Create example repository
- Create a quick start guide
- Error: Cannot find module 'utils' when executing local transform HOT 5
- Fix output codeshift init to ensure ts + build process is correct. HOT 1
- feat(@codeshift/cli): fetching packages from private registry HOT 10
- Add ability to pass path to codeshift.config.js HOT 5
- No `path` for the `applyTransform` with test utils
- pnpm workspace support
- Ability to bundle arbitrary dependencies via Community packages. HOT 1
- Missing utils
- InsertSpecifier breaks the reference by the use of spread
- Inconsistency in the name HOT 1
- CLI List not returning the correct status when remote package is not found
- Add hypermod config paths HOT 1
- Not possible to use @hypermod/cli to run transforms located in a private NPM package, right? HOT 9
- Default extensions are not working as expected with glob transform paths
- Validate: Unhelpful error generated when path is not specified
- Support typed config files
- Experimental module loader fails on remote package peer dependencies HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hypermod-community.