feat: use local babel config if it exists

[jquense]

No description provided.

[danez]

Would you consider this is a non breaking change? I wonder if I should create new branch for 4.x and merge that in there or if it is fine to be in the next release as new feature.

I can see that it might break for people that have their config not setup correctly and suddenly certain parser plugins are not active anymore. But I do not think this should be a common case.

[jquense]

yeah, I mean i'd say its technically probably a breaking change, but pretty unlikely to actually break anyone. I'd be tempted to say that any breakage would be positive too since it's likely surfacing a misconfiguration somewhere.

[danez]

👍

[jquense]

🎉

[jquense]

it occurs to me that we should still add an ability to manually pass through parser options for tool chains that don't depend on a babelrc on disk, like gatsby, which will do something similar to to this, defaulting basic options if there is no local config. It'd be nice if react-docgen could still work using those settings

[danez]

Yeah, we could create a a parserOptions flag that contains whatever the parser accepts. and we supply that to the parse function.

I'm not sure what babel would do internally, but I think it will merge config files with the supplied options where as programmatic options take precedence.

[danez]

After thinking more about it, I think I would do the next version with this PR as 4.0. I ran into breaking changes myself while building the website (https://reactcommunity.org/react-docgen/). I started creating it before this PR and then merged it afterwards which broke the webpack build because @babel/core uses fs which needs to be mocked away for browser builds. This wasn't the case before as @babel/parser has no dependencies.

Anyway I guess it is not a big deal to do a major version and then we are on the safe side even though for most users it shouldn't be a breaking change.

[jquense]

All good with me 👍 integers are cheap