Why using the whole babel plugins and flow definitions about idx

[yungsters]

Thanks for your question, @jsdario.

At Facebook, we use Flow for type-checking (almost) all of our JavaScript. We generally do not add support for proposals until they are beyond the experimental phase (which I believe is roughly defined as "Stage 2"). Adding support for the existential operator proposal is slightly more involved because it involves changes to not only Flow, but the parser.

The proposal was also not even Stage 1 when we initially introduced idx into our codebase. And until it is more mature, we need something that allows us to use this pattern while maintaining support with Flow. The benefit of using a function (even one with somewhat arbitrary constraints) is that the tooling ecosystem (e.g. IDEs, linters, and Flow) already know how to work with them.

Some people have raised the point that even though idx uses valid JavaScript syntax, it still required a custom Flow declaration and Babel plugin. As I mentioned above, the custom Flow declaration was very low cost, and we already have a precedent for Babel plugins that inline code functions in the name of performance (e.g. invariant).

As soon as the existential operator is further along and supported by Flow, the plan is indeed to codemod all call sites of idx at Facebook to use it. When that happens, I'll likely also open source the jscodeshift to do so.

I hope this answers your question!

[hzoo]

@jsdario for the first question, you can check the issue I made #1. I believe they just didn't know how far the proposal was and the status of it + Babel. Hopefully, we can have better communication in the future