Steve-Dee-Designs
/
woocommerce
mirror of https://github.com/woocommerce/woocommerce.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
woocommerce/plugins/woocommerce-blocks/assets/js/legacy
History
Mike Jolley b941b0c332 Update Dependencies to Latest Versions supporting React 16x (https://github.com/woocommerce/woocommerce-blocks/pull/4532) 
* Update storybook to 6.3.6

* @storybook/addon-knobs

* Remove need for wordpress-compose imports

This functionality exists in WP 5.5 so we don't need to import the package any more.

* Update to latest non 17x packages

* Composer update

* Fix for @babel/plugin-proposal-nullish-coalescing-operator and spinner style

* onSelect was called before init

* Add back env

* Update locks

* Revert browserlist config increase (ie11 support dropped needs separate discussion)

* update locks

* SVG can come from the external

* Import from components package where possible (5.5 has Gutenberg 9.2.0) and revert component package version change

* Revert component imports. Import from wordpress-components in the frontend context. This removes `wp-components`  dependency from all -frontend asset files.
 		2021-08-05 10:26:00 +01:00
..
README.md Rename js/components to js/editor-components (https://github.com/woocommerce/woocommerce-blocks/pull/3069) 2020-09-02 10:21:46 +02:00

README.md

This folder is used to hold any components/code that will get exported to the legacy build.

Currently, builds in this folder target WP < 5.3

When you add a file, add it in the same folder structure as the root.

So for example, if the original file was in:

assets/js/base/components/label/index.js

Then the legacy version will be located in:

assets/js/legacy/base/components/label/index.js

Note: you must copy all files related to the entry point for that module according to the path aliased.

Legacy builds will be identical to the main builds except:

  • files will have a -legacy suffix (so server can conditionally enqueue). It is expected that the server will load either the main or the legacy bundles, not both.
  • any imports not in the legacy folder will fallback to the main file.

How does the legacy system work?

Short answer, through the magic of WebPack! Long answer:

A. Aliases

We use aliases for paths covering anything that might need a legacy version. Then we have a dedicated builds for main and legacy code.

Current aliases are:

  • @woocommerce/base-components -> assets/js/base/components/
  • @woocommerce/base-hocs -> assets/js/base/hocs/
  • @woocommerce/editor-components -> assets/js/editor-components
  • @woocommerce/block-hocs -> assets/js/block-hocs

When importing, if outside the module referenced by that path, import from the alias. That will ensure that at compile time the bundles can pull from the appropriate location.

Example:

// will pull from '/assets/js/base/components/label/index.js in the main build
// will pull from '/assets/js/legacy/base/components/label/index.js in the legacy
// build.
import { Label } from '@woocommerce/base-components/label';

B. Webpack Plugin

The second part of the webpack magic is a custom plugin. Located in bin/fallback-module-directory-webpack-plugin.js, this custom plugin is used instead of the default Alias plugin. It handles trying a fallback if the original path aliased to does not exist. The fallback is a variation of the aliased path using the provided search and replace strings when instantiating the plugin. You can see it setup in the LegacyBlocksConfig.resolve.plugins property of the webpack.config.js file.