Join GitHub today
However, one cannot expect users to a) use Babel b) use two tools to generate a simple POT file.
So, why not support this in this little WP-CLI command here? :-)
Even though the Gettext library we use for the PHP part has a JS functions scanner, it is very limited: no support for comments, no clear indication which ECMAScript standard is supported, no usage of an AST, which is really important with such a quickly evolving language.
I decided to use Peast to traverse a script's AST, which was incredibly easy. We might even consider suggesting this for the Gettext library.
Still needs some tests, but so far it works fine.
referenced this pull request
Apr 27, 2018
While it's not implied, just to note that a common point of confusion is that its implementation as a Babel plugin has something to do with an opt-in decision to use newer language syntax, when in fact it was largely a combination of (a) taking advantage of the Babylon parser which, being at the core of Babel's language transpilation, is assumed to be well-maintained and (b) to combine into the same transpilation pipeline if one decides to use newer language features (as Gutenberg does, avoiding two separate parse steps).
This was referenced
May 3, 2018
@aduth Totally get the point. There's nothing wrong with that and I don't think we can get around that anyway.
Although JSX support is planned for Peast (the parser used in this PR), it makes more sense to use something like the Babel plugin for core and Gutenberg. That's why I've been working on things like #31 to make it easier to use both hand in hand.
As mentioned in yesterday's meeting, we'll likely test such a setup with Gutenberg and some other plugin(s) on WordPress.org soon. That way one at least won't have to generate these PHP files anymore during a build.