@sidewaysnyc/classic-wp-webpack v3.0.1
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:
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/' }
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/';
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); }
Have a 🍺
Dynamic imports
This is an optional step to support dynamic imports.
- Run
npm i babel-eslint eslint
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
2 years ago
2 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago
4 years ago