pinterest-for-woocommerce icon indicating copy to clipboard operation
pinterest-for-woocommerce copied to clipboard

Consider changing dependencies package versions based on DependenciesExtractionWebpackPlugin and L-2 support policy

Open ecgan opened this issue 3 years ago • 0 comments

Is your feature request related to a problem?

Note: in the following description, I'm using @wordpress/components package to describe the issue. The issue actually applies to all dependencies packages supported by DependenciesExtractionWebpackPlugin (@wordpress/dependency-extraction-webpack-plugin and @woocommerce/dependency-extraction-webpack-plugin).

In package.json file, we are using "@wordpress/components": "^12.0.8":

https://github.com/woocommerce/pinterest-for-woocommerce/blob/d8aa2db15074ecfcabb62af2c5bb925aad18751d/package.json#L11

The current WordPress version is 5.8, and with the L-2 support policy, this means we would need to support at least version 5.6.

In WordPress version 5.6, the @wordpress/components provided is version 11.1.5, see: https://github.com/WordPress/wordpress-develop/blob/8724f61f99db0ca853642f3f624083c56fa9de1a/package.json#L92

When we use the DependenciesExtractionWebpackPlugin with default configuration, the plugin would use the libraries provided by the WordPress environment. This causes issues like https://github.com/woocommerce/pinterest-for-woocommerce/issues/131 because during development we are coding based on "@wordpress/components": "^12.0.8" as specified in package.json, but during runtime the plugin uses the provided version 11.1.5.

Currently we solve the issue by resorting to bundling the newer @wordpress/components library in our plugin, configured in the webpack.config.js file, which means the plugin will use this bundled package regardless of the WordPress environment version:

https://github.com/woocommerce/pinterest-for-woocommerce/blob/d8aa2db15074ecfcabb62af2c5bb925aad18751d/webpack.config.js#L4-L11

The problem is that by doing this, every plugin will have its own version @wordpress/components, the JS file size will be bigger, and this would cost the user's network bandwidth.

Describe the solution you'd like

One solution to address this issue is to change the versions in package.json to match with the library versions provided by the minimum supported WordPress and WooCommerce version. With this, we would be developing based on the "lowest common denominator" approach.

Referring to the above @wordpress/components example, this means we would need to change package.json to "@wordpress/components": "11.1.5". We would also need to modify webpack.config.js so that we don't bundle the library.

When the plugin runs in WordPress 5.6, it would automatically use the library provided by WP, which would be 11.1.5. Everything should work as expected.

When the plugin runs in newer WordPress version (e.g. 5.8), the library provided might be a newer version (e.g. 13.5.6 - a made-up version number indicating major breaking changes), and things might fail due to breaking changes. For those situations that fail, workaround would need to be implemented. This could be done by manually copying and pasting code from older version 11.1.5 and including it in the plugin.

Note that this would require research and testing effort to make sure things work as expected across combinations of WordPress and WooCommerce versions.

ecgan avatar Sep 02 '21 19:09 ecgan