Skip to content

Releases: roots/bud

6.16.0

08 Sep 05:45
Compare
Choose a tag to compare

This update adds css module support for scss when using @roots/bud-sass, improves the CLI dashboard, and adds experimental support for pnpm and yarn berry to the bud ugprade and create-bud-app commands. It also includes dependency updates, bug fixes and other internal improvements.

What's Changed

New Contributors

Full Changelog: v6.15.2...v6.16.0

6.15.2

17 Aug 19:04
Compare
Choose a tag to compare

Patch: fixes a potential issue with resolving sass-loader and improves bud.cache interface and build dependency identification.

What's Changed

Full Changelog: v6.15.1...v6.15.2

6.15.1

15 Aug 05:23
Compare
Choose a tag to compare

Fixes issues with create- bud-app when not specifying any features (totally vanilla project) and improves CLI command cache to be mostly self-healing.

What's Changed

Full Changelog: v6.15.0...v6.15.1

6.15.0

08 Aug 05:19
Compare
Choose a tag to compare

This release is mostly focused on maintaining and improving existing features. The one new feature lets you opt-out of externalizing certain WordPress dependencies (if you are using @roots/bud-preset-wordpress or @roots/sage). For more information check out the updated @roots/bud-preset-wordpress docs.

⚠️ Potentially breaking change

@roots/sage: previously bud.splitChunks('single') was called for production builds. This is no longer the default for two reasons:

  1. If you have an editor entrypoint and an app entrypoint (common), it is possible that editor dependencies could be extracted into the common chunk. This can lead to Acorn enqueuing those dependencies for both app and editor, even if they were only used in one (since the shared vendor module contains references to the dependencies).
  2. This is very easy to address as part of your application and that approach is preferred. Especially now that top-level async/await is available for bud.js application modules.
  3. If you really want a vendors chunk, just call bud.splitChunks() or pass the --splitChunks flag.

What's Changed

New Contributors

Full Changelog: v6.14.3...v6.15.0

6.14.3

11 Jul 16:27
Compare
Choose a tag to compare

Fixes and improvements.

What's Changed

New Contributors

Full Changelog: v6.14.2...v6.14.3

6.14.2

10 Jul 07:19
Compare
Choose a tag to compare

Fixes #2365: bud@16.4.1 incompatible with stylelint@15.10.1

What's Changed

Full Changelog: v6.14.1...v6.14.2

6.14.1

06 Jul 16:29
Compare
Choose a tag to compare

Quick turnaround for an issue in 6.14.0.

If you are effected by this you can work around it using --no-cache until you can update.

What's Changed

  • 🩹 fix(@roots/entrypoints-webpack-plugin): stale caching by @kellymears in #2363

6.14.0

06 Jul 13:21
Compare
Choose a tag to compare

Top-level await, lazy compilation of async modules, CLI improvements, performance enhancements, and more.

🚨 Potentially breaking changes

  • deprecated: @roots/merged-manifest-webpack-plugin
  • deprecated: @roots/bud-wordpress-manifests
  • bud.console: removed. old methods consolidated with bud.dashboard.
  • bud.context.files: interface has changed. The module property for each value in bud.context.files is now an async function that returns the module. This is an undocumented internal, but some people might be using it.

Key changes

  • ✨ feature: top level await (enabled for ESM projects only)
  • ✨ feature: creates aliases from imports field of package.json
  • ✨ feature: dynamic modules now compiled lazily in development
  • 🏎️ performance: multi-config builds are now built in parallel
  • ✨ improve: config files now lazy loaded
  • ✨ improve(@roots/wordpress-theme-json-webpack-plugin): theme.json included in compilation module graph
  • ✨ improve(@roots/bud-tailwindcss-theme-json): Edits to tailwind.config.js now result in rebuild of theme.json
  • ✨ improve(@roots/entrypoints-webpack-plugin): entrypoints.json included in compilation module graph
  • ✨ improve(@roots/bud-dashboard): improved UI
  • ✨ add flag: --entrypoints.html (same as calling bud.entrypoints.set('emitHtml', true); emits partials containing <script> and <style> tags)
  • ✨ add flag: --dashboard (use dashboard stats vs. simple stats output)
  • ✨ add flag: --dashboard.assets (show/hide presentation of assets)
  • ✨ add flag: --dashboard.compact (truncated build summary)
  • ✨ add flag: --dashboard.entrypoints (show/hide presentation of entrypoints)
  • ✨ add flag: --dashboard.server (show/hide server info)
  • ✨ feature: for multi-compiler builds 1-9 will show stats isolated by compiler. 0 shows all compilers.
  • ✨ feature: d when viewing the dashboard will show detailed debug stats
  • ✨ feature: c when viewing the dashboard will present output with compact formatting
  • 🩹 fix: issues with bud.js cli error output
  • 🩹 fix: issues with bud.js internal module resolution cache
  • 📦 pkg(@roots/wordpress-transforms): small utility for translating @wordpress/* signifiers to wp-* enqueue handles and wp.* window references
  • 🗂️ typings(@roots/bud-framework): flatten organization of typings

Additional Notes

bud.js module resolution cache is now self-healing

The bud.js module resolution cache is now self-healing. If a build dependency was previously available at some path but is now unresolvable its entry will be updated while still preserving the rest of the cache. There should now be limited reason to use --force to manually flush the cache; it will probably only serve to make your next build slower.

--no-clean will be a future default

You can get a surprising performance boost by using the --no-clean flag (some test projects are >15% faster). Why delete and rewrite modules which have not been modified? This will be default in the next major release of bud.js.

You might not want to make a vendor chunk

If you are doing a lot of code splitting with imports, try disabling chunking and see if it improves initial page load (bud.splitChunks(false) or --no-splitChunks). The extra runtime code might not be worth it if you are already importing modules conditionally.

--ci will soon mean more than "run this without fanciness"

If you are using --ci solely to not display stats consider switching to --no-dashboard. There may be changes in the future to the behavior of this flag which are focused on CI environments specifically.

bud.js instance is now importable

The bud.js instance is now available as a named import from @roots/bud (import {bud} from '@roots/bud'). This allows for a bunch of stuff you couldn't do before. Like, as an example, configuring bud.js without an exported callback:

import {bud} from '@roots/bud'

bud.entry('app', ['app.js', 'app.css'])

You can also import the instance into other config modules or custom scripts. Not all tools will play nicely. Tailwindcss, for example, will try to bundle bud.js along with your tailwind config using jiti. It won't succeed (jiti can't handle import.meta).

Full Changelog

v6.13.1...v6.14.0

6.13.1

14 Jun 06:06
Compare
Choose a tag to compare

A feature rich (and mostly backwards compatible) set of improvements and fixes for bud.js.

⚠️ Potentially breaking changes

  • single runtimeChunk now enabled by default.
  • @roots/bud-eslint: warnings are not treated as errors by default.
  • @roots/bud-eslint: errors will cause files to not emit in production.
  • @roots/bud-stylelint: warnings are not treated as errors by default.
  • @roots/bud-stylelint: errors will not emit in production.
  • @roots/wordpress-theme-json-webpack-plugin: exported type Theme renamed to Schema.
  • @roots/bud-terser: is replaced by @roots/bud-minify.
    • you do not need to include this in your project; it is a transitive dependency of @roots/bud.
    • bud.terser deprecated in favor of bud.minify.js
    • bud.minimizeCss deprecated in favor of bud.minify.css

Core features

Enhanced support for tsconfig.json

You can now configure @src, @dist, compilation paths and aliases directly in tsconfig.json. Also works with jsconfig.json. This is nice for compatibility with the typescript compiler.

This feature is opt-in for now but will likely become a default in bud v7. To opt in set bud.useCompilerOptions to true in the config.

tsconfig key value
compilerOptions.baseUrl Set @src directory
compilerOptions.outDir Set @dist directory
compilerOptions.paths Set bud path handles and aliases
include Directories containing modules which should be treated as source. Same as calling bud.compilePaths

Example annotated tsconfig.json

{
  "extends": ["@roots/bud/config/tsconfig.json"],
  "compilerOptions": {
    /**
     * Source directory
     *
     * @remarks
     * This is the same as calling `bud.setPath(`@src`, `sources`)
     */
    "baseUrl": “sources",

    /**
     * Output directory
     *
     * @remarks
     * This is the same as calling `bud.setPath(`@dist`, `build`)
     */
    "outDir": “build",

    /**
     * Path aliases
     *
     * @remarks
     * This is the same as calling `bud.setPath()` and `bud.alias()`
     * Only the first path in each value will be used.
     */
    "paths": {
      "@fonts": ["fonts"],
      "@images": ["images"],
      "@scripts": ["scripts"],
      "@styles": ["styles"]
    },

    /**
     * Include type definitions
     */
    "types": [
      "@roots/bud",
      "@roots/bud-react",
      "@roots/bud-postcss",
      "webpack/module" // defines import.meta.webpackHot
    ]
  },

  /**
   * Configuration files
   */
  "files": ["bud.config.ts"],

  /**
   * Compiler paths
   *
   * @remarks
   * This is the same as calling bud.compilePaths()
   */
  "include": ["resources"],

  /**
   * Allow bud to reference tsconfig/jsconfig values
   */
  "bud": {
    "useCompilerOptions": true
  }
}

TSC compatible module imports

With the TypeScript Compiler you can ensure your outputted code is compliant with esmodules by mapping extensions in your import statements. For example, if you want to import a module from ./some-module.ts, you would likely want to import it like this:

import someModule from './some-module.js'

bud.js works the same way now, in practice. Now, if you want to write your import statements in a way that is compliant with TSC, you can.

bud.setPath now automatically sets aliased paths

If you set a path handle with bud.setPath it now sets up a path alias as well.

JSON schema available

JSON schema available at https://bud.js.org/bud.package.json. You can optionally add it to package.json for validation of package.json fields (including bud specific ones):

{
  "$schema": "https://bud.js.org/bud.package.json"
}

Improved extension options API

Every registered extension option now has a dedicated getter and setter. The getter prefixes the option key with get and the setter prefixes it with set.

Option Getter Setter
bud.extension.optionName bud.extension.getOptionName() bud.extension.setOptionName(value)

Lastly, know that the setOptionName always accepts a callback:

bud.extension.setOptionName(value => value)

Example

Let's say @roots/bud-eslint has a new option defined (since it does):

lintDirtyModulesOnly: EslintPluginOptions['lintDirtyModulesOnly']

Previously you could get this value like so:

bud.eslint.get(`lintDirtyModulesOnly`)

That still works, but now you have some additional options:

/** Get the value via a property */
bud.eslint.lintDirtyModulesOnly
/** Get the value via a function */
bud.eslint.getLintDirtyModulesOnly()

Similarly, in addition to bud.eslint.set:

bud.eslint.set(`lintDirtyModulesOnly`, true)

You can now set it with a dedicated setter method:

bud.eslint.setLintDirtyModulesOnly(true)

All such setter methods accept a callback:

bud.eslint.setLintDirtyModulesOnly(value => !value)

@roots/bud-postcss

  • The postcss configuration API has gotten a rework.

Refer to the updated documentation for more information.

@roots/bud-eslint

  • New options and methods exposed by bud.eslint
  • Configure eslint in your bud config

Refer to the updated documentation for more information.

@roots/bud-sass

  • New options and methods exposed by bud.sass

Refer to the updated documentation for more information.

@roots/bud-stylelint

  • New options and methods exposed by bud.stylelint
  • Configure stylelint in your bud config

Refer to the updated documentation for more information.

@roots/bud-swc

  • New options and methods exposed by bud.swc
  • Override base configuration for js and ts separately

Refer to the updated documentation for more information.

@roots/bud-tailwindcss

  • New options and methods exposed by bud.tailwind
  • Supports configuring tailwindcss directly in bud config

Refer to the updated documentation for more information.

@roots/bud-wordpress-theme-json

  • New options and methods exposed by bud.wpjson

Other changes

  • experiments.backCompat now set to false. bud doesn't need backwards compatibility with webpack 4 and the compatibility fixes come with performance penalties related to Array objects.
  • snapshot.buildDependencies uses a hash if bud.env.get('CI') is true; uses a timestamp otherwise.
  • snapshot.module uses a hash if bud.env.get('CI') is true; uses a timestamp otherwise.
  • snapshot.resolve uses a hash if bud.env.get('CI') is true; uses a timestamp otherwise.
  • snapshot.resolveBuildDependencies uses a hash if bud.env.get('CI') is true; uses a timestamp otherwise.
  • resolveLoader.alias defined for all registered loaders.
  • resolve.unsafeCache set to undefined (was false). default behavior is for unsafeCache to be used in development, and not used in production.
  • profile now set to true if --debug flag is true.
  • performance now set to false (was {hints: false}).
  • externalsType set to undefined (was var).
  • bud.context.logger is removed.
  • APP_TITLE fallback set for projects which use bud.html.
  • NO_SCRIPT fallback set for projects which use bud.html.
  • Typings for WordPress theme.json updated using current schema.
  • Build script now in place to help with future updates to WordPress theme.json.
  • Default css minimizer is now lightningcss (css parser used by parcel).
  • If using @roots/bud-swc css minification is handled by swc.
  • If using @roots/bud-esbuild css minification is handled by esbuild.
  • New documentation for bud.minify.

6.12.3

11 May 00:48
Compare
Choose a tag to compare

Bugfixes and bumped dependencies

Improvements

#2243 improves compatibility with pnpm

This change finishes work started in 6.12.2 make it less necessary to use the bud.js .pnpmfile.cjs compatibility shim.

You should also now be able to limit hoisting to @roots packages, if desired:

pnpm install --public-hoist-pattern="@roots/*"

When only hoisting @roots/* packages you will need to make sure your app dependencies are explicitly defined. Rule of thumb: if you import it in your app you will need to have it installed in your project.

The alternative is to hoist everything (same behavior as npm and yarn):

pnpm install --public-hoist-pattern="*"

Fixes

  • Fixes module resolution cache validation when swapping package managers.
  • Fixes issue with eslint not outputting to stdout/stderr in some configurations.