Recast needs additional maintainers

[conartist6]

@benjamn I am trying every way that might be possible to get your attention, because if I can't I'm forking the library.

[conartist6]

I think I'm just going to start work on the fork. It's macrome-js/macrome that I'm building which fundamentally relies on recast, so perhaps macrome-js/recast and @macrome/recast would be appropriate.

[conartist6]

Currently my organizations consist solely of me, but I've created them in the explicit hope that I can bring others in and form communities of trust and shared responsibility.

[conartist6]

I'm going to give this one day. Let's see how far out ahead I can get my fork in just one day of work.

[eventualbuddha]

@conartist6 I suggest talking with @benjamn about helping maintain recast. If you have a stake in it, then you're clearly more motivated.

[conartist6]

I've been trying rather aggressively, but no luck. I think the most helpful thing I can do is make my fork and show him what my direction would be if I had control over the package. I'm working on that right now.

I'm getting my fork ready to be a 1.0.0 release. I'm dropping support for everything that isn't absolutely essential.

I'm going to kick all the parsers out of the repo as they really need to be their own packages in order to configure deps correctly. I'll recommend babel-plugin-recast for babel users. No more one-size-fits-all parser options either.

I'm stripping away everything that isn't what the library is about to reduce the work involved documenting, maintaining, and versioning. No more run or runFile or runString. That is for other tools and libraries to build (and document). I'm not even exporting ast-types anymore because I don't want to merge those API surfaces and have to worry about which version is exported.

[conartist6]

Or maybe I should just change parsers to a different signature, something like parser => parser. I don't think recast should have the responsibility of actually requiring the parser, it just needs a way to let users specify parser options they want while recast dictates certain parser options that it needs.

[conartist6]

I've also ripped out the dependency on acorn as a default parsers. I just error now if your parser doesn't define tokens. I think most people will want to use @babel/parse, but I don't think recast should have dependencies on any particular parser at all. That probably means that recast shouldn't have a parse method at all but rather a wrapParse method. Again, stripping away the magic makes the library that much easier to document and maintain.

[conartist6]

Here's how I imagine usage looking roughly:

import { parse } from '@babel/parse';
import { wrapParseWithFormatting, printFormatted } from 'recast';

const parseFormatted = wrapParseWithFormatting(parse, 'babel');
const ast = parseFormatted(source, options);
// ast mutations
return printFormatted(ast);

[conartist6]

Replacing delete ... with ... = undefined as delete is a known perf-killer.

[conartist6]

Making the tests javascript instead of typescript. // @ts-check ensures they still get some basic benefits from typescript checking while devs get a few less things to worry about.

[conartist6]

Typescript doesn't understand self-references in js files (bug filed), and I'd prefer having those to having typescript. I think cleaning up the tests is going to be the biggest chunk of this work. The test cases need to be reorganized so that as many test cases as possible are expressed in a manner that is agnostic to the specific parser and ast structure being used.

[conartist6]

Actually I'm going to do the minimum amount of work necessary to get the test suite to pass then push, merge and push my fix for the parens issues, and continue working. I don't want to fall into the trap of verifying behavior which is wrong.

[conartist6]

Another thing I'm thinking about is that there's just very little left that recast is needed for at all. Recast has a lot of pretty-printing logic baked into, and these days all that really belongs in prettier. All that recast really does in an environment with pretty-printing is to ensure that certain line breaks remain untouched because prettier makes certain decisions about retaining its original formatting by comparing ast node locations to the source string.

I think the best thing to do for the long run would be to help prettier avoid dependence on the original source text so that the workflow would be:

• parse with prettier (prettier wraps the real parser)
• transform the AST
• print with prettier

And then we get to deprecate recast! I've created an issue to discuss the changes to prettier that would be necessary.

[eventualbuddha]

I can't say I disagree with most of your thoughts here. I also wonder about the future of recast in a world where many (most?) use Prettier.

That said, I decided to spend a little time getting things in slightly better shape and released v0.21.1: https://github.com/benjamn/recast/releases/tag/v0.21.1. If there's any specific PR you want me to prioritize, let me know and I'll hopefully get to it this week.

[conartist6]

Thank you!! Are you interested in my putting together PRs for the API changes I mentioned as being a potential 1.0.0? Even if the long term is to move away from recast, I think there's a strong argument to shipping a 1.x branch first. Don't wanna end up on the 0ver list!