Is sage switching from Bud to Vite?

sage
1

Checked last commits GitHub - roots/sage: WordPress starter theme with Laravel Blade components and templates, Tailwind CSS, and block editor support

2

Yes. More info about this is on discord server.

IMG_2367
IMG_23671206Ă—2174 411 KB

2 Likes
3

want to join discord aswell. how can i find it?

4

Access is a perk of sponsoring Roots: Sponsor @roots on GitHub Sponsors · GitHub

5

:thinking: Would it be possible to keep bud but let it wrap vite instead of webpack?
Using bud as an abstraction layer for those ever-changing build tool landscape?

7

Is that mean bud.js will not be maintained anymore?

8

This is quite a move, considering the time and investment made on bud but yap I think it is a good one,

9

Oof. Wish I had known this before integrating bud.js into a bunch of projects in the last year.

1 Like
10

I find the switch smooth actually, it is still doable will not take much of time

1 Like
11

How long would you estimate that the move took?

12

Yeah, it sucks when tools you rely on change. But the alternative was sticking with abandoned software. We didn’t make this decision lightly, and the web dev world has largely moved to Vite for good reasons. Happy to help with your transition if you need it.

2 Likes
13

Perhaps you could share steps taken so others that need to move from Sage 10 with Bud to Sage 11 with Vite. Could perhaps then even be added to Roots Sage documentation . Would be great.

1 Like
14

Maybe we could make a new thread on this to keep it all contained?

I’m also interested in knowing how much of an effort it is to switch from Sage 10 to Sage 11, so I’ll chip in for sure.

15

So when I understand this correctly, bud is/was basically a wrapper for webpack, it generated webpack configuration, managed webpack plugins.
And when sage uses vite now instead of webpack, it interfaces with vite instead, as a plugin and/or with vite configuration generation.

16

The biggest issue I’m facing so far in transitioning to Sage 11 is managing multiple js entry points. As a use case, I want a separate entry point for each custom block’s front-end script so that they can be enqueued and managed natively by WordPress’s block API by listing the script handle in block.json.

For example, in Sage 10, I could:

  1. Generate scripts with a single entry point in bud.js like:
.entry({
    myblock: ['@scripts/blocks/myblock'],
  })
.runtime('single')
  .splitChunks({
    chunks(chunk) {
      return ! [
        'myblock',
      ].includes( chunk.name );
    },
  })
  1. Register the script so the handle is available in WordPress’s script management API in setup.php. And Bud/Acorn takes care of the dependencies as well:
add_action(
    'wp_enqueue_scripts',
    function () {
       bundle( 'myblock' )->enqueue();
    }
);
  1. Enqueue the script in the custom block’s block.json, letting WordPress handle when the script is loaded based on block usage:
{
    ...
    "script": [
        "myblock/0"
    ]
}

How can I accomplish this in Sage 11? I can define multiple entry points in vite.config.js like:

export default defineConfig({
  base: '/wp-content/themes/custom-theme/public/build/',
  plugins: [
    tailwindcss(),
    laravel({
      input: [
        ...
        'resources/js/blocks/myblock.js',
      ],
...

But the generated script is a module, which cannot be registered and enqueued using the standard WordPress APIs. A dependency list is also only generated for for the editor.js entry point, so I have little insight into the needed dependencies.

I’m learning that Vite is not a 1:1 replacement for bud.js. Switching to js modules is a big change. Obviously I need to learn more about javascript development, but some more documentation or examples of how this works in the WordPress ecosystem (Sage is a WordPress theme, after all!) would be helpful. Any ideas how to tackle the case I described? Thank you!

17

Have you looked into using Script Modules in 6.5 – Make WordPress Core along with Vite::asset()?

I think the dependency extraction for other entrypoints could be explored in our Vite plugin. PR’s and outside contributions are always appreciated, especially for configurations like this that we haven’t shown signs/examples of actively supporting.

18

Thanks for the helpful response, @Log1x. I have looked at this, and have had limited success registering scripts with wp_register_script_module and loading them in block.js with the viewScriptModule key. But there are still a couple obstacles:

  1. Vite doesn’t handle dependencies, so I have to know and register the dependencies myself manually. That’s not insurmountable for a small block script, but also doesn’t provide the ease and reliability of Bud/Acorn bundles.
  2. Only a couple WordPress scripts are available as modules (See “Available Modules” and “Limitations” sections in Script Modules in 6.5 – Make WordPress Core). Not among them is @wordpress/i18n.
  3. I’m getting an esbuild error of Invalid loader value: "2" when in dev mode and with a .jsx entry point. It looks like Laravel Vite relies on the script being injected with the @vite directive and with the @viteReactRefresh as well (See https://laravel.com/docs/12.x/vite#react), which means I cannot use wp_register_script_module and WordPress’s script API to load my scripts if using React and dev mode.
19

Perhaps you can look at the source for the react refresh stuff here and come up with a solution. Definitely worth documenting if you come up with something, but I’m afraid I don’t use a configuration that would require any of this stuff so it’s not something I’m personally pursuing.

20

Do you need multiple entrypoints?

What about just using dynamic imports instead?

I don’t think your theme should be using multiple entrypoints. Also consider building your blocks out as a plugin instead of in the theme.

@wordpress/create-block – Block Editor Handbook | Developer.WordPress.org would be a good tool to use for building block plugins that’s very well supported.

21

Thanks for responding @ben,
I don’t know if I need multiple entry points, but it seems like that is WordPress’s preference. The API to enqueue scripts, manage their dependencies and add data from server side using the script_module_data_{$module_id} filter and the wp_add_inline_script function, as well as the block.json schema, seem to imply a separate block script for each block with a separate handle. Using Vite and dynamic imports, I have to manage where, when and how scripts and any dependent data from server side are injected.

I found Bud.js bundles were an understandable abstraction of the WordPress scripts API. Unless I’m missing something, Sage 11 is a big step away from managing scripts and styles the WordPress way. That’s not necessarily bad, but given Sage is still a WordPress theme, I’m struggling to implement scripts in the way I expect.

RE: blocks in theme vs plugin, creating them in a plugin is a great ideal. But I don’t think it makes much sense for a one-off block in a one-off theme with specific client functional requirements, nor for a block styled with Tailwind.