Object node type inconsistency with babylon7 and jscodeshift

[jgzuke]

When running with Parser: babylon7-7.0.0-beta.44 Transformer: jscodeshift-0.5.0 There is some inconsistency between what is shown in the tree view and in the jscodeshift output, the ObjectProperty shown in the tree is Property in jscodeshift, which is a bit confusing (see screenshot).

I believe this is because jscodeshift is using babel by default (which uses Property). Adding export const parser = 'babylon'; before my transform or const j = api.jscodeshift.withParser('babylon'); at the start of my transform works but doesn't change the autocomplete suggestions from the babel versions (ie j.Property still gets suggested over j.ObjectProperty).

Is there any way to fix the autocomplete issue here? Also since jscodeshift takes a parser, would it make sense to pass it whatever parser AST Exporer is using to avoid this confusion?

Thanks for all the great work on AST Explorer 🙌!

[timofei-iatsenko]

AstExplorer uses static pre-generated typings for TernJs. You can review them there jscodeshift.json

So there wasn't any kind of "dynamic" inference of typings, just static

[fkling]

As @thekip said, the auto-completion information is all staticly generated. You are right though, ideally we would show information relevant to the selected parser. I will keep this in mind for the future.

Also since jscodeshift takes a parser, would it make sense to pass it whatever parser AST Exporer is using to avoid this confusion?

It is confusing 🙁

The parser selection and the transform selecting are completely separate. I.e. the AST you are seeing might actually be different from what the transform uses, if you are not using the default parser the transform selected.

jscodeshift actually only supports three parser (old babel v5, babylon and flow). But not all transforms support something like this. I'm actually considering exposing the parser from the transforms itself instead of having a loose association between separate instances. Will see.