Add support for indirect translation function calls in JS

[Tug]

This change allows makepot on JS files to work for babel transpiled files. This change is similar to #204 but related to a babel behavior instead.

In some cases, babel will convert simple function calls to indirect ones (in the form of (0, __)( 'translate' )).

I guess this is done so that legacy ES5 script that uses strict mode are able retrieve the global window object using this.

In any case, babel often transpiles code like:

import { __ } from '@wordpress/i18n';

__( 'translate' );

Into:

var _i18n = _$$_REQUIRE(_dependencyMap[4], "@wordpress/i18n");

(0, _i18n.__)( 'translate' );

Testing instructions

• Download this JS file which uses @wordpress/i18n and is transpiled by babel (bundled by metro.js): https://github.com/wordpress-mobile/gutenberg-mobile/blob/develop/bundle/android/App.js
• Run wp i18n make-pot . --include=App.js -ignore-domain gutenberg-android.pot
• Notice strings are correctly extracted with this patch, otherwise the POT file is empty

[swissspidy]

Really nice, thank you!

[Tug]

Thanks for the review @swissspidy

I just added a last minute check to exclude a edge case: (0, __, somethingElse)( 'translate' )

[swissspidy]

No idea why the tests are timing out 😕

[Tug]

Just force pushed to give Travis another chance.

[Tug]

Seems like the test jobs for ubuntu xenial with php 5.6 are already close to 10min on the master branch, so it's possible we're reaching travis limit just by adding those few tests. Just experimenting with travis config a bit here ^

[swissspidy]

@schlessera any thoughts here?

[Tug]

It's green now, and it looked like those tests indeed needed a couple more minutes to finish. Happy to leave 5b9d70e in if you think it's the right approach

[swissspidy]

Interesting! Thanks for debugging.

I think for the sake of consistency with all other repos we should undo the travis_wait part again. But maybe Alain has some thoughts here.

[schlessera]

As @swissspidy already mentioned, the travis.yml file is supposed to be shared across all repos, so I'd like to find a solution that doesn't require changes to that.

The problem seems to be with PHP 5.6 only, so I assume there's something being used that has an extension on PHP 7+ but not on PHP 5.6.

So we'd need to find out what it is that is so much slower.
If there's an extension we can install to accelerate PHP 5.6 builds, I'm happy to add it centrally to all repos.
If not, we can skip the most expensive tests by strategically marking some tests as @require-php-7-0.

[schlessera]

Hmm, if Travis times out after 10 minutes on Behat, this means Behat didn't produce a single . for more than 10 minutes...

So there seems to be a single operation in the tests somewhere that runs for a very long time...

[schlessera]

I'll try to add a speed listener of some sort to Behat, reporting on the slow(est) scenarios and/or steps.

[simison]

Hi folks! Anything in particular stopping this PR from proceeding?

[swissspidy]

Hi folks! Anything in particular stopping this PR from proceeding?

I think mainly the issue with the tests timeout needs to be addressed.