New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JavaScript String Extraction #26

Merged
merged 20 commits into from Jul 4, 2018

Conversation

3 participants
@swissspidy
Collaborator

swissspidy commented Apr 27, 2018

More and more plugins rely heavily on JavaScript and the JS I18N library established by Gutenberg.

Since neither makepot.php nor this WP-CLI command support JavaScript, they had to build their own Babel plugin to extract JavaScript files.

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.

Fixes #30.

swissspidy added some commits Apr 27, 2018

swissspidy added some commits Apr 30, 2018

@swissspidy swissspidy requested a review from wp-cli/committers Apr 30, 2018

@aduth

This comment has been minimized.

Show comment
Hide comment
@aduth

aduth Apr 30, 2018

However, one cannot expect users to a) use Babel

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).

aduth commented Apr 30, 2018

However, one cannot expect users to a) use Babel

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).

@aduth

This comment has been minimized.

Show comment
Hide comment
@aduth

aduth Apr 30, 2018

b) use two tools to generate a simple POT file.

While it may be implemented as such in its current form, there's nothing which requires this to be a two-step process.

aduth commented Apr 30, 2018

b) use two tools to generate a simple POT file.

While it may be implemented as such in its current form, there's nothing which requires this to be a two-step process.

swissspidy added some commits May 2, 2018

@swissspidy

This comment has been minimized.

Show comment
Hide comment
@swissspidy

swissspidy May 9, 2018

Collaborator

@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.

Collaborator

swissspidy commented May 9, 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.

swissspidy added some commits Jun 19, 2018

Add `--skip-js` option
Useful when this is done in another build step, e.g. through Babel.
@swissspidy

This comment has been minimized.

Show comment
Hide comment
@swissspidy

swissspidy Jul 3, 2018

Collaborator

Did some updates today:

  • Fix merge conflicts
  • Add support for JSX
  • Add option to skip JS extraction altogether (see #30).
    Useful when this is already done in another build step, e.g. through Babel.
Collaborator

swissspidy commented Jul 3, 2018

Did some updates today:

  • Fix merge conflicts
  • Add support for JSX
  • Add option to skip JS extraction altogether (see #30).
    Useful when this is already done in another build step, e.g. through Babel.
Show outdated Hide outdated src/MakePotCommand.php
Show outdated Hide outdated src/MakePotCommand.php
Show outdated Hide outdated src/JsFunctionsScanner.php
Show outdated Hide outdated src/JsFunctionsScanner.php
Show outdated Hide outdated src/PhpCodeExtractor.php
Show outdated Hide outdated src/JsFunctionsScanner.php
Show outdated Hide outdated src/JsCodeExtractor.php
Show outdated Hide outdated src/PhpCodeExtractor.php
Show outdated Hide outdated src/PhpCodeExtractor.php
Show outdated Hide outdated src/JsCodeExtractor.php

swissspidy and others added some commits Jul 4, 2018

@schlessera schlessera added this to the 0.1.0 milestone Jul 4, 2018

@swissspidy swissspidy requested a review from schlessera Jul 4, 2018

@schlessera schlessera merged commit 7e11d8c into master Jul 4, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@schlessera schlessera deleted the js-code-extraction branch Jul 4, 2018

@schlessera

This comment has been minimized.

Show comment
Hide comment
@schlessera

schlessera Jul 4, 2018

Member

🎉

We will probably still need to iterate on this in the future, but having it merged now means we can better test it in actual use cases.

Member

schlessera commented Jul 4, 2018

🎉

We will probably still need to iterate on this in the future, but having it merged now means we can better test it in actual use cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment