v6.6.1

A bugfix release for bud v6.6.x.

🩹 @roots/bud-extensions — direct use webpack plugins not being called

• 🩹 fix direct use webpack plugins not being called
• 🧪 add unit test covering plugins added by signifier: bud.extensions.add('some-webpack-plugin')
• 🧪 add unit test covering plugins added as instance: bud.extensions.add(new SomeWebpackPlugin())
• 🧪 add unit test covering plugins added as simple object: bud.extensions.add({apply: () => void 0})

ℹ️ Release information

For more information review the diff to see what's changed.

v6.6.0

Features, improvements and fixes. Strongly recommended for multi-compiler users.

Read the release notes on bud.js.org

🚨 Breaking: bud.entry no longer parses files as globs

You can use bud.glob if you have need for this.

Example:

export default async bud => {
  bud.entry(`app`, await bud.glob(`@src/*.{js,css}`))
}

🚨 Breaking: Built-in extension keys are normalized

label	description	exposed
@roots/bud-extensions/cdn	Adds remote import functionality	bud.cdn
@roots/bud-extensions/esm	Adds ESM support functionality	bud.esm
@roots/bud-extensions/clean-webpack-plugin	Cleans output directory on build
@roots/bud-extensions/copy-webpack-plugin	Copies assets (used by bud.assets)
@roots/bud-extensions/fix-style-only-entrypoints	Removes JS output from entrypoints which only contain CSS
@roots/bud-extensions/html-webpack-plugin	HTML functionality (used by bud.template)
@roots/bud-extensions/interpolate-html-webpack-plugin	Adds create-react-app-like template variable support for HTML files
@roots/bud-extensions/mini-css-extract-plugin	Optimized CSS loading
@roots/bud-extensions/webpack-define-plugin	Defines variables which can be used in the application (used by bud.define)
@roots/bud-extensions/webpack-hot-module-replacement-plugin	Adds HMR support
@roots/bud-extensions/webpack-manifest-plugin	Emits manifest.json
@roots/bud-extensions/webpack-provide-plugin	Provides import(s) globally to the application

If you were using one of these labels directly, you'll need to update it. The upshot of this is that your editor will likely not only tell you that it's wrong but also offer the new key as a suggestion.

✨ Use package signifiers with bud.extensions.add and bud.use

Very convenient! Works for webpack plugins or bud.js extensions.

export default async bud => {
  bud.use('browsersync-webpack-plugin')
}

export default async bud => {
  await bud.extensions.add('browsersync-webpack-plugin')
}

This will only work if the plugin/extension is the default export.

✨ Expand all env values

Variables sourced from .env files in the path to the project are now interpolated using env-expand.
Previously, only the project directory would be expanded.

If you have an unescaped string that causes the expansion to fail the error will be caught.

✨ Better support for hot reload when using multi-compiler

Each bud.js instance's entrypoints are now registered with @roots/bud-client/hot. This helps to prevent conflicts
with reloaded modules when using multiple bud instances.

Some notes:

• Each instance now declares each previous instance as a dependency. This allows the bud.runtime to work even when using multiple instances.
• If you are using bud.runtime you will need to make sure that you are specifying single.
• If you want to modify the instance dependencies manually, you can use the (new) build.dependencies hook. Or, specify the dependencies in the context argument passed to bud.make.
• The bud.make docs have been updated.

Example of a custom dependsOn when setting up a child instance:

export default async bud => {
  bud.make({
    label: `example`,
    basedir: bud.path(`example`),
    dependsOn: [`some-other-instance`],
  })
}

🎉 Easier upgrades with bud upgrade command

Run bud upgrade to bump bud dependencies to the latest available version.
You will need to run the install after the command completes. This is a new command and is not yet unit tested.

@roots/bud-swc

🎉 @roots/bud-swc plugins are configurable

Call bud.swc.plugins to manage @swc/core plugins. You can pass an array of plugins (as demonstrated in the swc docs) or a callback
if you want to modify what's already there:

export default async bud => {
  bud.swc.plugins(plugins => {
    plugins.push([`swc-plugin`, {option: true}])
  })
}

If you haven't tried @roots/bud-swc you should consider it. This extension is no longer considered experimental. There is a strong case to be made for it replacing @roots/bud-babel in @roots/bud-preset-recommend for version 7 of bud.js.

@roots/bud-emotion

🎉 Supports @roots/bud-emotion

If you have @roots/bud-swc installed, @roots/bud-emotion will register emotion support with @swc/core.

@roots/bud-criticalcss

🎉 Option to disable CSS extraction

Disable critical CSS extraction by calling bud.critical.extract(false). This isn't generally recommended.

@roots/bud-criticalcss remains an experimental extension.

@roots/sage

🩹 Fix: proxy assets load when in dev mode

This fix requires acorn v3 and you must set a public path. You can opt-in with bud.sage.setAcornVersion('v3').

With the acorn version set to v3 assets should load when using the proxy directly in dev mode. You will still see 404 errors for the /bud/hot endpoint.

Internal changes

Nothing is required of you, but if you're curious, here's what's changed:

🩹 Fix: reload browser on watched files add/unlink

When files are added or removed from a watched directory path the browser will now reload.

🏷️ Typings: mapped extension options

You should now get useful, accurate intellisense and typechecking when using the bud.extensions api directly.

✨ CLI: warn when using bud.serve in a child compiler

It warns you to move it to the parent context. For now it also does this for you since it's an understandable mistake and will result in a TypeError.

✨ CLI: cleaner stack traces

There should be less duplication of emitted errors, more meaningful stack traces, and highlighting of important
parts of the error message.

⚙️ use nodenext to resolve node modules

We're using the nodenext tsc module setting. This enables top-level await for core bud.js packages 🥳.

⚙️ @roots/bud-api is now fully type-safe

strict mode is enabled! We're beginning to implement runtime validation using zod.

🧪 migrate from jest to vitest (#1850)

We switched from jest to vitest because of esm compatibility issues. It's pretty nice!
Hopefully we'll be able to run unit tests on the CLI now.

ℹ️ Release information

For more information review the diff to see what's changed.

v6.5.3

Bug fix for @roots/bud-sass users.

Fix: early process exit on errors thrown from loaders, even in development

An error thrown by Sass in development mode would cause the process to exit early. This issue could effect other plugins, but it surfaced via reports by @roots/bud-sass users.

Regardless, the fix is general and should apply to all extensions.

ℹ️ Release information

For more information review the diff to see what's changed.

v6.5.2

Bugfix release for multi-instance configurations. Read on bud.js.org.

Fix: Client script injection TypeError when no entrypoints are specified

Specifying an entrypoint is optional and, accordingly, its value may very well return undefined. This possibility was not handled correctly by @roots/bud-server/inject for multi-instance configurations, and would throw a TypeError if a child didn't explicitly set an instance. This is now fixed.

Fix: Certain conditionally applied extensions enabled/disabled globally in multi-instance

In multi-instance configurations the last call to Extension.enable() or Extension.disable() would be applied to all instances. This has been fixed.

ℹ️ Release information

For more information review the diff to see what's changed.

v6.5.1

Read the release notes on bud.js.org.

Small fixes and improvements related to argv, package.json and .env settings.

🩹 Fix: argv parsing

These flags were janky but now they are golden:

• --devtool - Set desired devtool
• --clean - Enable or disable build cleaning
• --discovery - Enable or disable automatic extension registration
• --flush - Clean webpack cache

This release also adds a --runtime flag, which is new. It doesn't accept everything bud.runtime does, but you can use it to specify basic options like single or multiple.

✨ Improve: env context

You can now set certain values in your .env:

• APP_BASE_PATH - the base path for your app
• APP_PUBLIC_PATH - the public path for your app
• APP_SRC_PATH - the @src path for your app
• APP_DIST_PATH - the @dist path for your app
• APP_STORAGE_PATH - the @storage path for your app
• APP_MODE - desired build mode

✨ Improve: package.json context

The options available under the bud key in package.json have been expanded:

{
  "bud": {
    "paths": {
      "base": string,
      "src": string,
      "dist": string,
      "storage": string
    },
    "publicPath": string,
    "extensions": {
      "allowlist": string[],
      "denylist": string[],
      "discovery": boolean
    }
  }
}

If you are using bud.allowlist or bud.denylist, please update to bud.extensions.allowlist and bud.extensions.denylist. You'll get a warning in your terminal for now; in a future release this will cause an error.

🩹 Fix: SSL proxy rewrites and documentation

The implementation and documentation for the bud.serve function had fallen out-of-sync. The bud.serve documentation and development server configuration guides are now up-to-date.

Additionally, path rewrites for proxied URLs served over SSL were defaulting to 0.0.0.0 for hostname. This has been fixed.

Example of the config which served as a test case for this release:

.proxy("https://ssl-test.test")
.serve({
  host: "ssl-test.test",
  cert: `${process.env.HOME}/.config/valet/Certificates/ssl-test.test.crt`,
  key: `${process.env.HOME}/.config/valet/Certificates/ssl-test.test.key`,
})

To apply the hostname fix to earlier versions of bud you will need to apply the rewrite in your config:

// This is no longer necessary in 6.5.1
bud.proxy('https://ssl-test.test', [['0.0.0.0', 'ssl-test.test']])

ℹ️ Release information

For more information review the diff to see what's changed.

v6.5.0

Filesystem API, S3 uploads, and more.

⚠️ This release deprecates the optIn property and decorator for extensions. This doesn't matter unless you are authoring an extension. If you are, you can probably just use dependsOnOptional instead.

✨ bud.fs

bud.fs is a new filesystem API for bud.js. It uses fs-jetpack and includes support for managing s3 assets.

Example of a file write operation:

await bud.fs.write(`README.md`, `# Hello, world!`);

Example of the S3 API which uploads @dist contents to a bucket after compilation:

bud.fs
  .setCredentials({
    accessKeyId: `***`,
    secretAccessKey: `***`,
  })
  .setEndpoint(`https://sfo2.digitaloceanspaces.com`)
  .setBucket("bud-test")
  .upload();

Check the bud.fs docs for more information.

✨ bud.after

Config function for executing tasks after the compilation is fully complete. This is useful for tasks that need to run after the compilation is complete, but don't need to be part of the compilation process (like uploading assets to s3!)

export default async (bud) => {
  bud.after(async (bud) => {
    await bud.fs.write(
      `dist/credits.txt`,
      `${bud.context.manifest.name} built by me!`
    );
  });
};

Execute a command with bud.sh:

export default async (bud) => {
  bud.after(async (bud) => await bud.sh(`yarn jest`));
};

Check the bud.after docs for more information.

🩹 Fix: duplicative logs

Some logs would be displayed twice in the terminal if they were emitted around the same time that the dashboard was being updated.
It was also possible, depending on user configuration, for requests for the dashboard to update to fire twice. This has been fixed.

1. console.* events are now caught by a new service: bud.bufferConsole. The service catches logs, trims and deduplicates them, and then emits them using an instance of the standard bud logger. If bud is invoked with the --ci flag the service will let them pass through normally.
2. The bud.dashboard service's stats method is now debounced. Duplicative calls should be ignored.

It's likely that our handling of process.stdout is still imperfect, but this is a step in the right direction.

🩹 Fix: notifications only fire once (macos)

In dev mode only the first compilation would result in a desktop notification. This has been fixed. You should now receive a notification for every compilation.

🩹 Fix: bud.env is not an instance of Container

bud.env was not an instance of Container and therefore did not have methods like is. This has been fixed and it should now behave as documented.

🩹 Fix: dynamically imported chunks not hashed

Dynamically imported chunks were not being hashed. This has been fixed.

🩹 Fix: @roots/bud-criticalcss

A breaking change in the critical package had broken this extension. This change has now been accounted for and the extension should work again. This extension is still listed as experimental.

ℹ️ Release information

For more information review the diff to see what's changed.

v6.4.5

A bugfix release for bud 6.4.x. Read release notes on bud.js.org

✨ @roots/bud-preset-wordpress: improve handling of WP_HOME

WP_HOME is now automatically set as a fallback proxy value. This means that if you don't call bud.proxy value in your bud.config.js file, the extension will attempt to use WP_HOME (if it is available and is a string value).

Previously, this value was set up front, which could cause errors if the value was malformed.

🩹 @roots/sage: bud.wpjson.useTailwindFontSize mutates config

This function no longer mutates the tailwind config. This caused tailwind to not generate css for font sizes.

✨ @roots/sage: filter theme.json values to those used in theme.extend

If you wish to limit generated values in theme.json to those included in theme.extend, you can now do so with an optional parameter passed to useTailwindFontFamily, useTailwindColors, and useTailwindFontSize.

export default async bud => {
  /**
   * Limit generated values to those used in theme.extend
   */
  bud.wpjson.useTailwindFontFamily(true)
}

If called with no arguments, the default behavior is to generate all values resolved by tailwindcss.

⚠️ @roots/bud-tailwindcss: bud.tailwindcss.resolveTailwindThemeValue renamed to bud.tailwindcss.resolveThemeValue

This is an undocumented method but some of you may very well be using it. It's name changed.

🩹 fix: --browser flag not working

Regression introduced in 6.4.0. Fixed (with added unit tests).

ℹ️ Release information

For more information review the diff to see what's changed.

v6.4.4

A bugfix release for bud 6.4. Mainly focused on multi-instance configurations. Read on bud.js.org

🩹 fix: @roots/bud-postcss not applied in multi-instance configurations

Fixes an issue where @roots/bud-postcss was not applied to child compilations. (#1702).

📕 docs: improve multi-instance documentation

Added documentation for configuring development server in a multi-instance setup to the multi-instance guide. (#1713)

ℹ️ Release information

For more information review the diff to see what's changed.

v6.4.3

Release notes are also available on bud.js.org

🩹 fix: @roots/sage errors logged when not using tailwindcss

Errors no longer reported when not using tailwindcss in a @roots/sage project.

🩹 fix: @roots/sage bud.wpjson doesn't generate colors

Colors now generated for theme.json when using bud.wpjson.useTailwindColors()

✨ feature: @roots/bud-tailwindcss reference tailwindcss values in js files

You can now easily use tailwind theme values in your app code by importing them from the (virtual) @tailwind/* alias.

An example:

import {black} from '@tailwind/colors'
import {sans} from '@tailwind/fontFamily'

export const main = () => {
  document.body.style.backgroundColor = black
  document.body.style.fontFamily = sans
}

Generating the imports can be memory intensive and increase build times, so it is opt-in.

app.tailwind.generateImports()

Better to generate imports only for specific keys (much less memory intensive):

app.tailwind.generateImports([`colors`, `fontFamily`])

This is a lot better than trying to import the actual tailwind.config.js file to read these values as the values are fully resolved (merged with defaultTheme, plugins applied, etc.)

And it's a lot better than importing tailwindcss/resolveConfig and doing it in the app code because of the transitive dependencies taken on by that import.

It's also better than pre-compiling a static json file because these values are tree-shakeable. The entire generated json for the default tailwind config is ~100kb.

The above example adds ~5kb to the overall bundle (and only because tailwind has so many default colors). If you use terser (bud.minify) the difference is entirely negligible.

ℹ️ Release information

For more information review the diff to see what's changed.

v6.4.2

Release notes also available on bud.js.org

👉🏼 known issue: [@roots/sage] errors logged when not using tailwindcss

If you are not using @roots/bud-tailwindcss you will see errors in the logs when running bud build or bud dev.
This is a known issue and will be resolved in the next release. It isn't a sign that anything is wrong in your project.

✨ improve: [@roots/sage] bud.wpjson now fully resolves tailwind configs

Previously, bud.wpjson could only generate a theme.json based on a fully static tailwind config file. This excluded tailwind configs that
defined theme properties using functions and also meant that plugins would not be applied.

Now, bud.wpjson functions related to tailwindcss will fully resolve the tailwind config file and generate a theme.json based on the
processed config. This should mean that any tailwind config can be used in conjunction with bud.wpjson.useTailwindColors() and similar functions.

🩹 fix: build errors return non-zero exit code

For production builds, build errors will now result in a non-zero exit code. This regression was introduced in 6.4.0. It is now fixed.

🩹 fix: eslint.config.js support

eslint.config.js configurations are now supported.

🩹 fix: bud repl

The bud repl command has seen significant improvements since 6.4.0. It fixes a bug in 6.4.1 related to syntax highlighting.

ℹ️ Release information

For more information review the diff to see what's changed.