[request] Allow for custom modes

[kupoback]

Agreement

• This is not a duplicate of an existing issue
• I have read the guidelines for Contributing to Roots Projects
• This is not a personal support request that should be posted on the Roots Discourse community

The feature

Looking for the ability to either add a custom compiler mode outside of just development or production, or the inclusion of a local mode.

Use case

When our frontend developers work locally, we want to be able to serve the files locally, with source-maps, and unminified.
When we deploy to a dev or staging server, we still require the ability to have the CSS files with source-maps, unminified, but we are not serving the site with Node.

Notes

I've already tried playing around with different bud.config.json files of .local and what not, but I was unable to get it to work correctly. I am stuck with either bud dev or bud build production and cannot manipulate or adjust the bud dev in any way to serve a proxy URL locally via the package.json scripts, not am I able to really make a config file that's specific to a local environment.

[talss89]

Continuation of: https://discourse.roots.io/t/setting-up-browser-sync-for-local-but-not-for-a-dev-staging-site/25121

The bud compiler modes map to Webpack 5 modes, this is logical. It is not intended that Webpack compiler modes should be created / extended - they underpin how the module bundler works at its base level. I do not think custom Bud modes should be implemented.

@kupoback - Sorry to chip in here again, but it seems like you haven't found a solution yet. What you're looking to achieve is already supported - see the suggestion in the Discourse thread using environment variables and .when(). Note: BUD_SOURCEMAPS is just a var name I came up with, it could just as well be FOO_STAGING_MODE.

Your dev and staging servers, should operate in bud production mode, with minimization disabled and sourcemaps enabled based on an inline env var in the package.json script definition. If the env var isn't set, it should revert to 'true' production mode, with minimization and no sourcemaps. Bud's dev mode will always emit JS runtimes, even if you aren't using HMR - this is deliberate and links back to the design of Webpack.

Unless I'm completely mistaken. In which case, I'll dig a hole to climb into.

@kellymears, please could you validate this advice?

[kellymears]

@talss89 this is correct.

there is no plan to release any type of custom mode for bud.js. I second the recommendation to use when.

something to this effect:

# .env
BUD_LOCAL=true

bud.when(
  /* condition */
  bud.env.is(`BUD_LOCAL`, true),
  /* when true */
  bud => bud.devtool(`inline-cheap-module-source-map`),
  /* when false (optional) */
  bud => bud.minimize()
)

[kupoback]

I guess I updated my discourse thread but not here.

I was looking for 2 things for local, 1 of them for dev, and none for prod.

Local: Watcher + Sourcemaps
Dev: Sourcemaps
Prod: As is.

I will take a look at the .when however, as this may be exactly what I need and as such, not anything needed from you guys. I'll see what I can do to get it to read from a Bedrock env file, instead of looking for the env file in the Sage folder!

[talss89]

Great, remember you can set env vars in a yarn script: VAR_NAME="val" bud build

[kellymears]

@kupoback bud.js will read envvars from anywhere in the theme path automatically, starting at root. Conflicting env will be overridden with the lower directory taking precedence. So if you define VAR_NAME in /srv/project/.env and /srv/project/app/themes/sage/.env the sage value will be the one that ends up in the bud.env store.

from querying bud.env.all() in the bud repl command:

❯ yarn bud repl                                                                                                                                                     

bud.env.all()                                  page 6/11
                                                                                                                                                                                  
 ...
 "WP_ENV": "development",
 "WP_HOME": "http://example.test",
 "WP_SITEURL": "http://example.test/wp",
 ...

[esc] quit  [tab] clear  [↓] next  [↑] prev  [return] eval

WP_* vars are not defined in my sage directory, just bedrock.

[kupoback]

Thank you, this actually helped out tremendously. I didn't think about fetching fro the .env file at all, and was able to build out a nice solution to serve sites locally with sourcemaps, show sourcemaps for a dev env, and deliver a production build for staging and production.