Setting up browser sync for local but not for a dev/staging site

I am working with Sage 10, and working on the bud.config.js to try and allow only browser sync if the user is running a particular script in the package.json.

Basically, for our dev/staging sites, the frontend developers want the ability to see the source-maps, but with the way the Sage 10’s package.json is outlined, you have either yarn bud or yarn bud production. The former will serve the site, which is great locally, but the latter will minimize.

I know that I can prolly use CLI to tag onto the script, but I fear this may cause a lot of confusion and push back from my frontend development team of being too complex.

Is there a way I can set specific flags in the package.json scripts to execute the proxy/serve methods in the bud.config.js file, OR set up my own custom mode, instead of just development or production? I also believe the option of using a .env file would also be out, again due to adding another layer of complexity.

This is my package.json currently:

"scripts": {
    "dev": "bud dev ",
    "build": "bud build",
    "production": "bud build production",

And here is my bud.config.js

module.exports = async (bud) => {
            "@sageAdmin": "@src/admin_assets",
            // React script alias'
            "@sageReact": "@src/react",
            "@sageRedux": "@src/react/Redux",
            "@reactComponent": "@src/react/Components",
            "@reactPages": "@src/react/Pages",
            "@reactUtil": "@src/react/Util"

            app: ["@scripts/app", "@styles/app"],
            editor: ["@scripts/editor", "@styles/editor"],
            admin: ["@sageAdmin/css/admin_styles", "@sageAdmin/js/sage-admin"],
            sageReact: ["@sageReact/app"],
            blog: ['@sageReact/Pages/Blog/blog-index'],

        .assets(["images", "fonts"])





        .when(bud.isDevelopment, bud => bud.devtool())

Hi @nmakris,

I believe adding a custom build mode isn’t Bud-ish. It seems like the assertion isDevelopment || isProduction holds true throughout Bud.

I’m not sure what you’re trying to configure - whether you’d like a production build with source maps, or a dev build without HMR.

There doesn’t appear to be an easy way to disable the HMR server in dev mode, although setting .proxy(false) effectively disables it. But if you don’t want to use the HMR server on port 3000, just don’t use it - visit the proxied URL directly. Development builds will always generate JS runtimes.

If you want to add a variation to a production build (like adding source maps), you can use environment variables. There’s no need for an .env:

"scripts": {
    "dev": "bud dev ",
    "build": "bud build",
    "production": "bud build production",
    "staging": "BUD_SOURCEMAPS=1 bud build production"
.when(process.env.BUD_SOURCEMAPS, bud => bud.devtool())

Hopefully that mechanism will help you build what you’re after?

Also, just FYI your build and production tasks are identical; bud build is an alias for bud build production.

Basically what is needed is this

Local Server: serve and watch files, have source maps – No issues here
Development Server: do not serve and watch files, have source-maps – Issue found here
Staging Server: do not serve and watch files, have source-maps – Issue found here
Production Server: normal functionality that’s found in the Sage 10 bud config – No issues here


Thanks - that’s helped me understand!

It seems like using production mode for both development and staging servers, but switching on .devtool() based on an environment variable is the way to go here then.

It is not possible AFAIK to disable watching / serving when in development mode.

Yeah, I was able to get the source-map fully grasped using .when(bud.isDevelopment => bud.devtools()) but sadly, as you mentioned, there was no way to integrate something like this for serving as well, as it would disable the functionality for my local.

I did also try setting a script in my package.json with something like the following, playing around with using = or single quotes to wrap the flags, but they also were not taking or being respected.

"scripts": {
    "dev": "bud dev --proxy https://url.test --port 3000"

We’ve seen the --proxy flag not work correctly on Bud 6.12.0 recently too. The workaround we are using is:

.proxy(app.context.args?.proxy ?? 'http://fallback-when-no-arg-passed')

The same could be applied for .port().

1 Like

I’ll give this a go, and see if it’s exposed with the CLI flags. Thank you

Ended up doing the following reading from an .env file for Bedrock. Got this help from Github

bud.env.isNotEmpty('WP_ENV') && bud.when(`WP_ENV`, 'local'),
    bud => {
                ? bud.env.get('BUD_LOCALHOST')
                : 'http://localhost:3000')
                    ? bud.env.get('WP_HOME')
                    : ''
    bud => bud.minimize
.when(`WP_ENV`, 'development'),
    bud => bud.devtool(`inline-cheap-module-source-map`),
    bud => bud.minimize
1 Like