Use project's installed version of @babel/core and babel config if possible

[jedwards1211]

As seen here, the parser only uses some default options: https://github.com/wix/vscode-glean/blob/master/src/parsing.ts#L8

Babel configs can vary widely and the only proper thing to do in any AST-modifying extension is use the project's locally installed version of @babel/core and have it load the project's babel configuration.

[borislit]

@jedwards1211. Thanks for the awesome suggestions! Using local babel config makes perfect sense (although I will have to merge the config, the extension requires to work, with it). How would you do it? Load .babelrc somehow?

As for local version of @babel/core - the main issue I see here is version discrepancy. Say you are using version 8 and the extension uses version 7. What happens then?

[jedwards1211]

Here's how I do it: https://github.com/codemodsquad/jscodeshift-choose-parser/blob/master/index.js

Generally .babelrc will be configured correctly to parse code within the project, so there should be no need to merge your own options. The only exception is if someone has embedded their Babel config in options for babel-loader with Webpack. (Which I could also try to detect and support in jscodeshift-choose-parser...)

You can always fall back to trying your current parser setup if something fails for any reason or the locally installed version of Babel is incompatible. But your current parser setup might fail if people are using proposals like the pipeline operator, for example, which is why using the local Babel config is likely more foolproof.

[borislit]

Gocha @jedwards1211 ! Awesome idea. Care for a PR?

[jedwards1211]

Eventually yeah, about to go on a short vacation though. Also I need to verify, when using this approach, if the user upgrades their version of @babel/core, if the extension would get stuck using the prior version...I assume using resolve on each command takes care of that, but I should double check.