Bud v6.3.0 released

bud
1

bud v6.3.0 released

For a better reading experience, read on bud.js.org.

:sparkles: Roots browserslist

@wordpress/browserslist-config is licensed in a way that is not compatible with bud’s overall licensing ideals. Accordingly, we’re offering a drop-in replacement: @roots/browserslist-config.

There are three configurations available, pick the one most suited to your requirements:

Export Target Description
@roots/browserslist-config >1% usage Similar to @wordpress/browserslist-config
@roots/browserslist-config/current >.5% usage Similar to @facebook/docusaurus
@roots/browserslist-config/broad last 3 versions Similar to @shopify/browserslist-config

:sparkles: Simpler postcss config

🚨If you are addressing the default plugins by their handle you will need to update it
  • postcss-import becomes import
  • postcss-nesting becomes nesting
  • postcss-preset-env becomes env

More information added to docs

Essentially 100% of postcss users want three things from postcss: @import, nesting, and the arcane magic that is postcss-preset-env. Some want more, but none want less. And out of that 100%, pretty much 100% of them want the plugins in that order.

That 100% figure is absolutely a fabrication, but I do think there is something to it.

Nobody wants nesting before import because it just doesn’t work. Everything goes sideways immediately. You probably have an @import right at the top and postcss has no way to know what to do with it.

So, that basic ordering is locked down now (at least by default — check the docs for information on how to override). The result is that its much simpler to play with the baseline config without breaking everything.

Example: add some-example-plugin {`bud.postcss.setPlugin('example-postcss-plugin')`}
Example: modify postcss-preset-env options {`bud.postcss.setPluginOptions('env', { features: { customProperties: false, }, })`}

:sparkles: Better bundles

It’s pretty passe to just go throwing the entirety of node_modules into a vendor.js file with bud.splitChunks.

Why not be cool and target only the dependencies that benefit from it?

Introducing a better, simpler way to code split: bud.bundle.

bud.bundle('react')

Or, group some dependencies you always use together:

bud.bundle('react', ['react', 'react-dom'])

Nice chunk!

You’re not restricted to node_modules, use your own code with it too, if you want. The only rule is that the chunk members are being addressed by directory. So, to match your own code you need to make a directory for it.
You can always use bud.splitChunks if you need more control than that.

:adhesive_bandage: Safer env expansion

bud.js still sources envvars from process and its path, but will no longer attempt to expand values outside of the .env found in the project root directory.

This could cause issues if ${ and other such character strings were used in bud’s path without being escaped.

:thought_balloon: Extension specific notes

:sparkles: @roots/sage: dynamic imports

If you’re using @roots/sage, you should try doing a dynamic import with @roots/sage/client/lazy:

import lazy from '@roots/sage/client/lazy'

const makeConfetti = async () => {
  await lazy(import('canvas-confetti'), confetti => confetti())
}

:adhesive_bandage: @roots/bud-vue: scoped styles

A small configuration issue in the @roots/bud-vue extension has been fixed and scoped stylesheets should no longer make total destroy.

:thought_balloon: Notes on public path

I’m just going to come out and say it: if you are not serving from web root you should specify a public path.

This is what I’m imagining you saying right now:

  • “But, I shouldn’t have to set a public path!”
  • “Setting a public path is unncessary”
  • “A base URL once robbed me on the L train and now I only take ubers”

Here are my responses:

In all seriousness we’ll get more specific & explicit about this in the documentation but I can say that in the future bud will expect users not serving assets from web root to define a public path. Right now we characterize
it as “if you want to use dynamic imports”, but it will be simplifying to just assume it is set.

I think it is a reasonable requirement and certainly a common one. And, for what it’s worth, I’m afraid to take the L train, too.

3 Likes