Add prettier transformer

[josephfrazier]

This makes it possible to use astexplorer like https://prettier.github.io/prettier,
but with the ability to cross-reference the code with its AST.

[RReverser]

If you want to upgrade Prettier, you need to provide new regexes to exclude irrelevant parsers (they're structured differently in Prettier now). Unless you want to allow all of the parsers, but then need to check that transform actually works with each of them.

[josephfrazier]

Ah, fixed in 6927696

Since this is a JavaScript/etc transformer, I eliminated the non-JS parsers.

[azz]

Unless you want to allow all of the parsers, but then need to check that transform actually works with each of them.

That would be great. With the next version of prettier there's an opportunity to modify the AST so AST Explorer would be the perfect place to try that out.

// codeExample.txt
export default ({ traverse }) => ({
  parser(code, { babylon, /* flow, typescript, postcss */ }) {
    const ast = babylon(code);
    traverse(ast, {
      Identifier(path) {
        path.node.name = path.node.name.split('').reverse().join('');
      }
    });
    return ast;
  }
});

Alternatively, like the postcss transformer:

// codeExample.txt
import traverse from "babel-traverse";

export default {
  parser(code, { babylon }) {
    const ast = babylon(code);
    traverse(ast, {
      Identifier(path) {
        path.node.name = path.node.name.split('').reverse().join('');
      }
    });
    return ast;
  }
});

[RReverser]

@fkling I wonder if we can / should limit certain transformers to a list of supported parsers to make sure they're not invoked with something that produces an incompatible AST? (and how that would look like in the UI)

Maybe let parsers and transformers define the standard which they produce aka "estree", "babel", "typescript", etc. to filter them out by such group?

[fkling]

@RReverser

Maybe let parsers and transformers define the standard which they produce aka "estree", "babel", "typescript", etc.

Regardless of anything else, I think that would be a good idea.

I wonder if we can / should limit certain transformers to a list of supported parsers

IMO the current structure (select parser or select transform + parser) is wrong and confusing. What I started in #197 was to unify parsers and transforms:

Unified interface

One big difference is that transformers also have to provide a parse() method (instead of specifying the ID of a parser to use). This method is supposed to delegate to the parser the transform is using. That means, whether a tool is a transformer only depends on whether or not it implements a transform method.
Overall this should simplify the store logic and other places on the website.
Another positive side effect of this: The "parser settings" logic can now be reused for transformer settings.

The reasoning behind this is:

• At the moment, parsers and transformers are completely independent. I.e. any settings you make to a parser doesn't affect the transform at all. This is confusing. The version the transform is using internally might also be different than the version we provide.
• By delegating to the transformers own parser we can show an AST that is closer to what the transformer is actually using.
• Not all transformers allow you to change parser settings anyway.

Of course not all transformers expose the parser. In that case we have to bundle the right version and "replicate" the parsing process (as long as it's reasonable to do so).

I.e. in the end users wouldn't select a parser or a parser + transform anymore, but just a "tool". A tool exposes a parse() or a parse() and a transform() method.

However, if a transform actually accepts an AST as input, then we should allow to select a compatible parser (which is where your other suggestion comes in).

[fkling]

Is this good to go? Code looks fine to me.

[josephfrazier]

Yup, I just resolved the merge conflict, and don't have any more changes to make.