Areas for improvement - Low hanging fruit

[danieldelcore]

Continuing from here, I wanted to create this discussion to capture and crowdsource low-hanging improvement teams for jscodeshift.

I recommend we limit suggestions to:

• Quality of life improvements
• Repository/dev loop
• Testing
• Documentation
• Modernisation

Any architectural or breaking changes should be the topic of another discussion or RFC.

References:

• Bringing jscodeshift up to date #500 (comment)
• Bringing jscodeshift up to date #500 (comment)
• Announcement: Maintenance and Future Plans #587

To start us off the items that are top of mind for me:

Automate versioning & releases

Use a tool like changesets to automate changelogs, versioning, and releases so we don't have to wait for someone from meta to cut a release and increase the rate of change.

Documentation

A lot of the API is undocumented (or the docs are hard to find), we could create a fairly simple docs site via Docusaurus or similar paired with some automation that outputs API and type information to markdown.

Typescript

This one is debatable, but I think a type system would really improve DX, especially when working with the AST/collection APIs.

Test coverage

Better test coverage across the jscodeshift API. would make the library more resilient to changes bubbling up from the parsers, recast and ast-types.

A recent example where a regression was introduced via a bump of recast: #534 (comment)

[Daniel15]

Regarding the documentation, @mohab-sameh from Codemod recently created a new site to replace the old JSDoc docs (#592). It's live now at https://jscodeshift.com/. Before this existed, there was a docs folder in source control that contained auto-generated API docs.

[danieldelcore]

Ah – Really nice I missed that!

[mohab-sameh]

@danieldelcore please let me know if there is anything you'd like to see in the new docs. I'm planning to improve them over time.