Sage Wordpress on windows + WSL with Bud : build very slow (more than 1 minute)

Hi !

I’m working on a Wordpress website with sage theme for the first time. I just install it and run the build :

yarn dev
yarn build

And the one or the other command line took a very long time to finish. I have to wait 60s to 1m30 ! I think I’ve done something wrong.

Here is my environnement:
OS : windows + WSL
Server : WAMP
Sage 10.2.0
Mode development
@roots/bud 6.3.3
webpack 5.73.0
node 16.16.0

My package.json :

  "name": "sage",
  "private": true,
  "browserslist": [
    "extends @roots/browserslist-config/current"
  "engines": {
    "node": ">=16.0.0"
  "scripts": {
    "dev": "bud dev",
    "build": "bud build",
    "translate": "yarn translate:pot && yarn translate:update",
    "translate:pot": "wp i18n make-pot . ./resources/lang/sage.pot --include=\"app,resources\"",
    "translate:update": "for filename in ./resources/lang/*.po; do msgmerge -U $filename ./resources/lang/sage.pot; done; rm -f ./resources/lang/*.po~",
    "translate:compile": "yarn translate:mo && yarn translate:js",
    "translate:js": "wp i18n make-json ./resources/lang --pretty-print",
    "translate:mo": "wp i18n make-mo ./resources/lang ./resources/lang"
  "devDependencies": {
    "@roots/bud": "6.3.3",
    "@roots/bud-sass": "^6.3.5",
    "@roots/sage": "6.3.3"

My bud.config.mjs

// @ts-check

 * Build configuration
 * @see {@link}
 * @param {import('@roots/bud').Bud} app
export default async (app) => {
     * Application entrypoints
      app: ["@scripts/app", "@styles/app"]

     * Directory contents to be included in the compilation

     * Matched files trigger a page reload when modified
    .watch(["resources/views/**/*", "app/**/*", 'resources/styles/*', 'resources/scripts/*'])

     * Proxy origin (`WP_HOME`)

     * Development origin

     * URI of the `public` directory

If you have some hint to speed up my build, it will be amazing !

I saw on the doc that there is a

yarn start

command that just compile the scss and js, that would be great. But it return this error : error Command “start” not found.

Thank for all the help you can get me :pray:

This is WSL 1 or 2?

I moved my project folder into the Linux file system (~/src/) and run the tools from there, it is much, much faster and more stable than letting WSL bridge between the Windows host file system and the Linux one on WSL.

This is WSL 2.

If I move the project, how can I use WAMPL ? I should install LAMP on my Linux ?

1 Like

Yeah that would probably work better. You could also use Trellis or another vm-based solution.

@strarsis could please explain or link a reference as to how you did that? That sounds excellent


WSL 1 has faster cross-file system I/O than WSL 2, but it lacks lots of compatibility features, but even with WSL 1 the performance is still noticeably reduced when accessing the windows file system from within.
I have tried lots of things in the past, also before containers and WSL 1/2: VM with samba share, VM with NFS share, VM with Samba share and OverlayFS with vendor/non-code parts mounted from the Linux file system, rsync adapter, etc. But it is always slow, no performant solutions there.

There had been two reasons for why I wanted to have this hybrid approach: 1) The actual source code should reside on the Windows native file system (which I also maintain and back-up) and 2) Windows programs with their UI should be used to edit the files, with the exception of Linux tools that would be invoked inside the Linux system.

Both problems can be solved though:

The source code can be stored on the Windows native file system, but a work copy of it is replicated into the Linux file system. Using git is the right approach for this: The source code should be in version control anyway, the repository is cloned and a work copy is checked out into the Linux file system. Changes there can be easily pushed back to the repository.

Files editing shouldn’t be affected by the slow I/O when accessing those files on the WSL Linux system from native Windows programs.
VSCode offers something cool here though: It is installed and used as native Windows program, but it can also install a server in the WSL system, and use it more efficiently from within.

My workflow currently looks like this:

  • Private GitLab server for hosting the repositories (mostly used for Trellis deployments, but it is helpful for development, too). GitHub now also offers free, unlimited private repositories by the way (if I get this right).
  • Clone and check out a working copy from the external repository into the WSL Linux file system.
  • Use VSCode with WSL support enabled to work with the source code, use Docker for Desktop with WSL support to run containers inside WSL for full performance.
  • Push changes to the working copy back to the external repository, VSCode does this also very nicely.

Note: Everything listed above can also be achieved without VSCode, as with singular tools like git. I like what IDEs offer, but I don’t want to be dependent on one.