Size Change: 0 B

Total Size: 1.04 MB

_{compressed-size-action}

Can you still load unminified version of bundles shipped with the plugin when consuming from the zip file?

Can you still load unminified version of bundles shipped with the plugin when consuming from the zip file?

Could you elaborate on the use-case? The production build will include both an unminified index.js and a minified index.min.js. With this change, production will be restricted to enqueuing the minified files, though, and I think that's fine. The main reason the unminified .js files are shipped with the plugin is to support the translation machinery AFAIK (see: #23960 (comment)).

Can you still load unminified version of bundles shipped with the plugin when consuming from the zip file?

Could you elaborate on the use-case? The production build will include both an unminified index.js and a minified index.min.js. With this change, production will be restricted to enqueuing the minified files, though, and I think that's fine. The main reason the unminified .js files are shipped with the plugin is to support the translation machinery AFAIK (see: #23960 (comment)).

One of the main goals of #23960:

I propose the Gutenberg plugin follow the convention, including minified and readable JavaScript and enqueuing one or the other based on SCRIPT_DEBUG.

and implemented in #31732 was:

Add support for WordPress' SCRIPT_DEBUG constant. When it's true, the unminified version of the script should be loaded, instead.

This would remove this integration.

Can you still load unminified version of bundles shipped with the plugin when consuming from the zip file?

@gziolo That's something that this PR reverts back to the state before #31732, and something that could be further improved.

When consuming the plugin from the (official) ZIP file, and running WordPress with SCRIPT_DEBUG on, the browser will load minified bundles with valid sourcemaps that point back to the unminified and unbundled sources.

After #31732, SCRIPT_DEBUG would trigger loading unminified bundled assets, but without sourcemaps. Because sourcemaps are not output by the ReadableJsAssetsWebpackPlugin plugin.

But that was a regression for the npm run dev workflow. That workflow creates unminified bundled assets, identical to what ReadableJsAssetsWebpackPlugin would write. So, SCRIPT_DEBUG doesn't make a difference there: both index.js and index.min.js are identical. But index.js doesn't have a sourcemap.

To summarize, this patch reverts one minor change that #31732 introduced, keeps all the other desirable improvements, and avoids reverting the entire #31732.

Let me know if that looks OK to you.

One of the main goals of #23960

Well that means that the goals of #23960 are not fully achieved yet. We generate and ship readable JS sources with the plugin, but the SCRIPT_DEBUG flag ignores them, loading minified files with sourcemaps. But sourcemaps are not currently shipped with the plugin, are they? So a developer that uses the official ZIP package of Gutenberg is stuck with minified files.

I assumed that @fullofcaffeine's primary motivation was to solve issues with extracting translations. That's solved and continues to be solved.

Another piece of context is that @talldan wants to revert #31732 because it breaks npm run dev and that is considered an urgent issue. That's why I'm attempting a quick fix that avoids the revert and I'm deferring a 100% perfect solution for later.

@jsnajdr, I'm fine with whatever approach you take. I didn't mean to block this PR. I wanted to clarify where we are now, what this patch changes and if we need to work on a follow-up. It looks like I was correct about the missing integration with SCRIPT_DEBUG so it should be tackled next.

OK, I'll merge it then. The npm run dev issue is fixed and we'll continue to work on making the SCRIPT_DEBUG flag work, with sourcemaps and everything.

I assumed that @fullofcaffeine's primary motivation was to solve issues with extracting translations. That's solved and continues to be solved.

Exactly, sorry if I wasn't clear, and thanks for clarifying, too @jsnajdr @gziolo.

OK, I'll merge it then. The npm run dev issue is fixed and we'll continue to work on making the SCRIPT_DEBUG flag work, with sourcemaps and everything.

Sounds good, I can take a look soon(ish). I think the next step is to make the ReadableJsAssetsWebpackPlugin output source-maps for the unminified files for both the production and dev builds, right?

Exactly, sorry if I wasn't clear, and thanks for clarifying

I thought it was clear, too, because it was the context of all our discussions around this, but then I looked at the PR description and the linked issue and it was all about SCRIPT_DEBUG and nothing about translations 🙂

the next step is to make the ReadableJsAssetsWebpackPlugin output source-maps for the unminified files for both the production and dev builds, right?

On dev build, we don't need the plugin at all. It's useful only for creating production assets that are going to be shipped in the ZIP package to users. But yes, for the production build, the next step is to make the plugin output sourcemaps, too, and to also include them in the published ZIP package.