74421 configure build pipeline#74426
Conversation
|
Size Change: 0 B Total Size: 3.08 MB ℹ️ View Unchanged
|
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Adding @youknowriad to review the approach here |
| if ( fileName.endsWith( 'vips.wasm' ) ) { | ||
| fileName = VipsModule; | ||
| return VipsModule; | ||
| } else if ( fileName.endsWith( 'vips-heif.wasm' ) ) { |
There was a problem hiding this comment.
@swissspidy Should we just leave off libheif/vips-heif.wasm here for now to avoid the licensing issues?
There was a problem hiding this comment.
SGTM. That would make the bundle smaller too.
2115d9f
into
feature/74352-new-wordpress-vips-package
This reverts commit 2115d9f.
jsnajdr
left a comment
There was a problem hiding this comment.
I'm curious where this package is used and how did it work before this patch.
Esbuild doesn't handle .wasm out of the box, so it probably failed with error when encountering the import 'wasm-vips/vips.wasm' statement.
Webpack converts the import to an async module and generates a .wasm asset with its own URL. That's something we want to prevent with this PR, for compat reasons.
We should be careful about how we load and use the vips package now. The built index.mjs file is now 17MB, because it inlines all the WASM data. When there's no longer async loading in place, we should somehow provide it ourselves.
| // Handle imports like 'wasm-vips/vips.wasm'. | ||
| if ( ! args.path.startsWith( '.' ) ) { | ||
| const { createRequire } = await import( 'module' ); | ||
| const require = createRequire( args.resolveDir + '/index.js' ); |
There was a problem hiding this comment.
This code should use esbuild's own resolver, with build.resolve. We have an existing example in the externalizeAllExceptCssPlugin, which also prevents loops.
I have some doubts whether we need this onResolve callback at all. Esbuild should be able to do the *.wasm resolution on its own, and then we only need a onLoad( { filter: /\.wasm$/ } ) callback that does the custom loading.
Or maybe we don't need any callbacks at all, not even onLoad, and the entire job can be achieved with an esbuild option:
loader: { '.wasm': 'dataurl' }
It wasn't properly used before AFAIK. I added the initial version for the experimental client-side media processing but hadn't glued it to the media upload logic so far. |
* Add wasmInlinePlugin to inline vips * Add wasm inlining tests * doc blocks
* Add wasmInlinePlugin to inline vips * Add wasm inlining tests * doc blocks
* Add wasmInlinePlugin to inline vips * Add wasm inlining tests * doc blocks
This PR configures the build pipeline to inline the vips WASM binary as a Base64 string during the webpack build process. This is part of the client-side media processing feature that enables image processing in the browser using WebAssembly.
Fixes #74421
Testing Instructions
Build Verification
packages/vips/build/contains output files with inlined Base64 WASM contentpackages/vips/build/index.cjs: