Skip to main content

Running multiple instances

Experimental

This is a newer feature of bud.js. It is possible that this API will change in future releases. We suspect these changes will be driven by the needs of users.

It is possible to configure more than one compilation in a project.

For a single page app this isn't really that useful. However, for WordPress or a Symfony app — or anything with different build requirements for different application components — it is potentially very useful.

Creating child instances​

To create a new child instance, we can use bud.make.

The simplest implementation sets the label of the compiler with a string, and provides a configuration callback:

export default async bud => {
  await bud.make('theme', async theme => theme.entry('index'))
}

More complex implementations can be achieved by supplying context overrides using an object:

export default async bud => {
  await bud.make(
    {label: `plugin`, basedir: bud.path(`plugin`)},
    async plugin => plugin.entry(`index`),
  )
}

See the bud.make documentation for more information.

Using the --filter flag​

The other benefit is a potentially massive workflow improvement. Let's say that we have to work on the theme more often than the plugin. With the above config we don't have to rebuild the plugin code again just to work on our theme code.

We can use the bud cli to only run the compiler we need using the --filter flag.

$ yarn bud build --filter theme

If you had more than two instances it might make sense to want to target more than one compiler, and --filter supports that:

$ yarn bud build --filter theme --filter plugin

Configuring unique extensions per compiler​

By default, all extensions will be applied to all compilers in the project.

If the extensions differ between compilers you can either use the --no-discovery flag or set the bud.extensions.discovery property in your root package.json to false to prevent extensions from being automatically injected.

Then, you can manually load the extensions on a per-compiler basis:

export default async bud => {
  await bud.make('theme', async theme => {
    theme
      .use('@roots/bud-postcss')
      .setPath('@dist', 'dist/theme')
      .entry('theme', ['theme.css'])
  })

  await bud.make('plugin', async plugin => {
    plugin
      .use('@roots/bud-react')
      .setPath('@dist', 'dist/plugin')
      .entry('plugin', ['plugin.js'])
  })
}

Configuring the development server​

Any configuration of the development server should be done in the parent context.

This includes:

export default async bud => {
  /**
   * Configure dev server in the parent context
   */
  bud
    .watch([`resources/views/**/*`, `app/**/*`])
    .proxy(`https://sage.test`)
    .serve(`http://0.0.0.0:3000`)

  await bud.make(`app`, async app => app)
  await bud.make(`editor`, async editor => editor)
}

Child instances do not feature their own development server. This is incorrect:

export default async bud => {
  await bud.make(`app`, async app => {
    app
      .watch([`resources/views/**/*`, `app/**/*`])
      .proxy(`https://sage.test`)
      .serve(`http://0.0.0.0:3000`)
  })

  await bud.make(`editor`, async editor => editor)
}