classic-wp-webpack

It helps to forget about any configuration on the classic Wordpress projects.

Everything inside this project could be easily modified once you install this package and the build directory has been created.

The idea is make this as simple as just npm i and start developing but at the same time having the option to modify the rules or add anything related with webpack for your specific project.

If you want to install this on your wp project.

Note: Make sure you have the latest node version. Now working with v12.13

New Project

Run:

npm i @sidewaysnyc/classic-wp-webpack@latest --save-dev

Then:

• Add to scripts "update-webpack": "classic-wp-webpack-update" on package.json
• Run npm run update-webpack

Note:

If you already installed the script will replace build folder and wont ask you again about the domain

Existing project

• [ ] Go to the repository and theme path
• [ ] Remove all dependencies that are on classic-wp-webpack dependencies already
• [ ] Remove build folder
• [ ] npm i @sidewaysnyc/classic-wp-webpack@latest --save-dev
• [ ] Add to scripts "update-webpack": "classic-wp-webpack-update"
• [ ] Run npm run update-webpack
• [ ] Run npm run watch
• [ ] See if everything is running well

Steps to update

• [ ] Go to the repository and theme path
• [ ] Change version of the classic-wp-webpack package.json
• [ ] Add to scripts "update-webpack": "classic-wp-webpack-update"
• [ ] Run npm run update-webpack

Analyze dependencies

• Run npm run prod --analyze, by adding flag --analyze will run a server and shows you details of your webpack dependencies

Note: This last step will replace /build folder, so make sure you have custom code versioned to avoid losing your code. It could be necessary to adjust .babelrc or some extra file.

Migrating to V2

V2 brings Hot Module Reloading (HMR) for CSS and initial support for dynamic imports.

In all previous instances where we use webpack we often have to deal with the fact that scripts, styles, images, etc are not stored in the root of the domain like www.example.com/app.hash.js, but rather in some nested directory.

To deal with this we have resorted to many hacks (see $asset-path in SASS). Fortunately there is a way to fix all such problems: by using webpack's publicPath option.

This option allows you to tell webpack that all assets are in a subdirectory, this works for images defined in SCSS, dynamic JS imports and even HMR.

In short, here's what you need to do:

1. Add a PUBLIC_PATH option to your build settings file, with the value of the full path from the root of the domain to the dist folder:

   // build-settings.js
   module.exports = {
     ...,
     PUBLIC_PATH: '/wp-content/themes/[my_theme]/dist/'
   }

2. Ensure your $image-path and/or $fonts-path in SASS are relative and not absolute:

   Wrong ❌

   $asset-path: '/wp-content/themes/xyz/assets/';
   $image-path: $asset-path + 'images/';
   $fonts-path: $asset-path + 'fonts/';

   Correct ✅

   $image-path: '../images/';
   $fonts-path: '../fonts/';

3. In the PHP function that reads the manifest file, make sure to remove all logic that detects if the asset is a URL or a file, just do:

   function getHashedAsset($fileType, $isEditor = false)
   {
       $feature = !$isEditor ? 'app' : 'editor';
       $manifestFile = get_template_directory() . '/dist/manifest.json';
       $manifest = json_decode(file_get_contents($manifestFile), true)[$feature];
   
       $assetPath = $manifest[$fileType] ?? '';
   
       return filter_var($assetPath, FILTER_VALIDATE_URL) ? $assetPath : get_home_url(null, $assetPath);
   }

4. Have a 🍺

Dynamic imports

This is an optional step to support dynamic imports.

1. Run npm i babel-eslint eslint

2. Update your ESLint's parser (so that import() is not a syntax error):

   {
       "rules": {
           ...
        },
       "parser": "babel-eslint"
   }

jQuery support

Add flag to build-settings.js

  LEGACY_AUTO_IMPORT_JQUERY: true