babel-plugin-makepot: Don't bundle .pot files

[ockham]

Describe the bug

Currently, the the @wordpress/babel-plugin-makepot is writing extracted translation strings to one .pot file. There seem to be at least two issues with that:

1. We (mostly @akirk and @zinigor) have repeatedly run into issues with strings being not included into the resulting .pot file, both on Calypso and Jetpack. We suspect that this might be due to a race condition when running the plugin via webpack (due to webpack's threading mechanism).
2. It's hard to have the plugin produce e.g. one .pot file per webpack entry point.

There's a fairly high chance that both issues can be solved by having the plugin write one .pot file per input (.js) file, and leave merging of those files to a tool like msgcat. TBH I think that's the way that babel plugins are supposed to work (mapping one input file to one output file, rather than many-to-one). To use the analogy of JSX/ES6+-to-JS transpilation, it's Babel that transpiles each file individually, and it's Webpack then bundles them.

(I'd also argue that using a babel plugin like makepot alongside webpack is a fairly common scenario, so the plugin shouldn't break in that setting.)

This means that Gutenberg would then require a post-processing step to invoke msgcat, but this is hopefully not insurmountable, even if Gutenberg is not using webpack itself -- might be as easy as adding that command to an entry in package.json's scripts. (It would also obviously require a new major release of @wordpress/babel-plugin-makepot.)

To Reproduce

No perfectly isolated steps yet, but at least two independent cases. I need to find the Calypso one; the Jetpack one is being discussed at Automattic/wp-calypso#30303

Additional context

Automattic/wp-calypso#30410 (comment) -- that PR was going to introduce webpack loaders in order to allow producing one pot file per entry-point, which I considered undesirable.

/cc @simison @sirreal

[ockham]

/cc @omarreiss @youknowriad @aduth curious to hear your thoughts.

FWIW, @sirreal discovered the following (quoting from Automattic Slack, p1548746476396100-slack-jetpack-gutenberg thread):

Yesterday I tracked down that you have to remove the cache or disable the babel-loader (the webpack loader, not Babel itself) cache in order for the file to be generated. That's odd, makes it seem like the file is created as a side effect of Babel rather than its primary output. I'm webpack.config you set the Babel loader cacheDirectory to false if I recall correctly.

(Our impression is that this confirms that a Babel plugin shouldn't be writing to an aggregate file.)

[aduth]

TBH I think that's the way that babel plugins are supposed to work (mapping one input file to one output file, rather than many-to-one).

This is an accurate assessment, and acknowledged, for what it's worth. Babel expects to receive a single source input (file). How we've implemented it is outside its intended usage, and was done so as an intended simplification of the toolchain.

[aduth]

Related: #12559

Gutenberg will soon not use babel-plugin-makepot internally.

[ockham]

Thanks Andrew. Looking at #12559, it's not clear to me what is going to take care of string extraction in lieu of the makepot plugin? Is WP.org/the plugin repo taking care of that now (including JS)?

[aduth]

@ockham Yes, the idea would be that Gutenberg would rely on the string extraction to occur within the plugin repository. I've since been brought to the attention of a yet-unresolved ticket which may hinder this effort, however: https://meta.trac.wordpress.org/ticket/3876