# Lando + Bedrock + Bud/Sage Configuration **URL:** https://discourse.roots.io/t/lando-bedrock-bud-sage-configuration/22740 **Category:** bud **Tags:** bedrock, sage10 **Created:** 2022-03-28T19:40:48Z **Posts:** 33 ## Post 1 by @noahott — 2022-03-28T19:40:48Z I have a partially working configuration of [Lando](https://lando.dev/) with Bedrock and Sage 10 using Bud 5.7.3. Changes in Bud 5.4.0 have made the configuration older guides in Roots Discourse and elsewhere no longer function. I’m posting this hear to share and to request assistance in getting the bud/Lando configuration fully functional. .lando.yml (within a sage10 theme and bedrock) ``` name: lando-bedrock recipe: wordpress config: webroot: web proxy: appserver: - bedrock.lndo.site theme: - theme.bedrock.lndo.site:3000 services: theme: type: node:16 ``` bud.config.js (the default Sage config + .serve()) ``` /** * @typedef {import('@roots/bud').Bud} bud * * @param {bud} app */ module.exports = (app) => app /** * Application entrypoints * * Paths are relative to your resources directory */ .entry({ app: ['@scripts/app.js', '@styles/app.scss'], editor: ['@scripts/editor.js', '@styles/editor.scss'], }) /** * These files should be processed as part of the build * even if they are not explicitly imported in application assets. */ .assets(['images']) /** * These files will trigger a full page reload * when modified. */ .watch([ 'tailwind.config.js', 'resources/views/**/*.blade.php', 'app/View/**/*.php', ]) /** * Target URL to be proxied by the dev server. * * This is your local dev server. */ .proxy('http://bedrock.lndo.site') .serve('http://0.0.0.0:3000'); # 0.0.0.0 instructs node server to bind to all addresses ``` With this configuration, the Bud dev server is accessible from [http://theme.bedrock.lndo.site](http://theme.bedrock.lndo.site) on both ports 80 and 3000. The only issue now is that bud does not properly intercept URLs, so clicking any link takes me back to the site I’m proxying, instead of the dev url. I’m assuming this is because Bud doesn’t know the proper URL since I’m not passing it in to bud.serve and only defining it for Lando. Passing in ‘[http://theme.bedrock.lndo.site:3000](http://theme.bedrock.lndo.site:3000)’ to bud.serve results in the error `Error: listen EADDRNOTAVAIL: address not available 172.19.0.5:3000 ` and then Bud chooses a different random port. I thing needed for a full working configuration is a way for Bud to bind to all ports while also specifying a desired dev url so the rewriting will work properly. In the Bud release notes, Kelly mentions it is now possible to pass in additional options to .serve : [Release: 5.7.0 | bud.js](https://bud.js.org/blog/5.7.0/) I think these are the options he refers to: [HTTP | Node.js v16.14.2 Documentation](https://nodejs.org/dist/latest-v16.x/docs/api/http.html#httpcreateserveroptions-requestlistener) I’ve tried to find a way to pass bud.server the desired dev address while overriding the addresses to bind on, but have not yet been successful with that. I’m not sure if this is possible or if we need some additional options in Bud. I welcome anyone’s thoughts or insights on these issues. --- ## Post 2 by @noahott — 2022-03-29T15:16:53Z With the update to Bud 5.7.4, this no longer works. When I try to access the theme.bedrock.lndo.site URL bud crashes with the error ``` ❯ firing action event.proxy.interceptor 1/1 ┏ TypeError ━━━━┓ ┃ ┃ ┃ ┃ ┃ Invalid URL ┃ ┃ ┃ ┃ ┃ ┗━━━━━━━━━━┛ ``` --- ## Post 3 by @kellymears — 2022-03-29T22:40:03Z I don’t really know anything about lando but I think you want something like this: ``` app.serve('http://example.lndo.site'); app.hooks.action('event.server.before', async (app) => Object.assign(app.server.connection, { url: new URL('http://0.0.0.0:3000'), }), ); ``` That said, this request feels weird. There must be a way for lando to map the public URL within the container to the URL outside the container. Or, one could run `dev` outside of the container. But, like I said, I don’t use lando. --- ## Post 4 by @Davide_Prevosto — 2022-03-30T07:57:22Z Actually, I am running `yarn dev` or `yarn build` outside the container. --- ## Post 5 by @cim — 2022-03-30T14:05:06Z I have tried every configuration and suggestion in this and the previous thread, but no luck. It was mentioned a few times that it is probably server configuration problem and am glad to accept that. But hot reloading worked with my Lando configuration (similar to the one from OP) and Sage 10-beta3 (Bud 5.3.2) and not with the later versions of Sage. So something must have changed in bud \> 5.4 (or its dependencies) that isn’t playing well with Lando. I tried to compare Bud version 5.3.2 with later versions, but I am afraid I am not knowledgeable enough to make enough sense of it. @kellymears maybe you could give me an indication of where I should start digging I moved to Trellis for now, but that is just not the best option for my use case. --- ## Post 6 by @ben — 2022-03-30T14:17:26Z > [@cim](#): > > @kellymears maybe you could give me an indication of where I should start digging :x: This isn’t a Bud issue. Please don’t ask the maintainer of Bud to fix your Lando config. --- ## Post 7 by @ben — 2022-03-30T14:17:38Z --- ## Post 8 by @ben — 2022-03-30T14:19:26Z As I noted in the now closed guide about Sage and Lando, there aren’t bugs in either Lando or Bud preventing them from working with each other. We are personally using Lando with Bud on both a Sage project and a regular Laravel project. Feel free to ask questions amongst yourselves to try and figure this out. If you are trying to get someone from the Roots team to solve this for you, you’re going to have to hire them for consulting. --- ## Post 9 by @cim — 2022-03-30T14:36:54Z I am sorry. I am a long time fan and user of Sage. Just not that knowledgeable, That’s why I asked where I (myself) could start digging for a solution. I don’t want to give up on Sage. Edit sorry @noahott that this thread was unlisted probably because of my comment --- ## Post 10 by @RistoKaalma — 2022-03-30T18:45:03Z @ben - kindly asking if this topic could be listed again? I too am hoping for further community driven elaboration here and believe that the community can most likely benefit from this topic. --- ## Post 11 by @ben — 2022-03-30T18:59:33Z This topic isn’t locked. It will be listed once the discussion moves away from the repeated “has anyone gotten this to work?” question, which is asking for someone else to figure out the solution and deliver it to you. We frown on “free work” posts. --- ## Post 12 by @cim — 2022-03-30T20:39:14Z I have spent maybe two full weeks on trying to figure this out myself. I really am not asking for free work, just for a little bit of help. And I am willing to put more time in it if someone points me in the right direction. --- ## Post 13 by @ben — 2022-03-30T21:36:37Z I’d suggest just using Browsersync in the meantime if you’re unable to configure Lando. 1. install browsersync: `yarn add browser-sync browser-sync-webpack-plugin --dev` 2. modify `bud.config.js`: ``` # @ bud.config.js const bs = require('browser-sync-webpack-plugin') ... .use(new bs({proxy: 'http://example.test'})) ``` > **full config example** > > ``` > const bs = require('browser-sync-webpack-plugin') > > module.exports = async (app) => { > app > .entry({ > app: ['@scripts/app', '@styles/app'], > editor: ['@scripts/editor', '@styles/editor'], > }) > .assets('images') > .watch('resources/views/ **/*', 'app/** /*') > .use(new bs({proxy: 'http://example.test'})) > }; > ``` --- ## Post 14 by @cim — 2022-03-31T12:59:08Z @ben So far this seems to work well for me. Should have thought of this myself I feel, but thanks for providing this workaround! --- ## Post 15 by @cim — 2022-03-31T13:16:37Z It’s even better: my lando config now also seems to work with bud 5.7.6 (without the workaround) --- ## Post 16 by @noahott — 2022-04-01T20:41:36Z As @cim first noted, as of bud 5.7.6 Lando and Bud seem to be playing nicely together. My working config looks like this: .lando.yml ``` name: lando-bedrock recipe: wordpress config: webroot: web proxy: appserver: - bedrock.lndo.site theme: - theme.bedrock.lndo.site:3000 services: theme: type: node:16 ``` bud.config.js ``` /** * @typedef {import('@roots/bud').Bud} bud * * @param {bud} app */ module.exports = (app) => { app /** * Application entrypoints * * Paths are relative to your resources directory */ .entry({ app: ['@scripts/app.js', '@styles/app.scss'], editor: ['@scripts/editor.js', '@styles/editor.scss'], }) /** * These files should be processed as part of the build * even if they are not explicitly imported in application assets. */ .assets(['images']) /** * These files will trigger a full page reload * when modified. */ .watch([ 'tailwind.config.js', 'resources/views/**/*.blade.php', 'app/View/**/*.php', ]) /** * Development URL to be used in the browser. */ .serve('http://theme.bedrock.lndo.site'); } ``` The bud.proxy line is also not required if WP\_HOME is set. With this config, the bud dev server can be accessed from [http://theme.bedrock.lndo.site](http://theme.bedrock.lndo.site). --- ## Post 17 by @noahott — 2022-04-04T17:47:27Z Additionally, this config assumes you are running everything with the Lando containers, i.e. `lando composer install`, `lando yarn`, `lando yarn dev`… --- ## Post 18 by @noahott — 2022-04-04T18:01:43Z I ran into an issue on 2 of 3 projects I had set up like this where Bud would include CSS and JS assets using an absolute URL with port 3000 that would not work outside of the containers. Interestingly enough, one site worked perfectly, including assets with relative URLs, without any apparent differences in configuration and dependency versions. To solve this problem, the app.hooks.action code can be added below the .serve line in bud.config.js: ``` /** * Development URL to be used in the browser. */ .serve('http://theme.bedrock.lndo.site'); /** * Fix JS & CSS assets included with incorrect URL by updating the server config AFTER the * dev server has been started. */ app.hooks.action('event.server.after', async(app) => { Object.assign(app.server.connection, {url: new URL('http://theme.bedrock.lndo.site')}) }); ``` --- ## Post 19 by @aksld — 2022-04-05T06:47:12Z Last solution from @noahott works. Without hooks, CSS and JS are not enqueued. --- ## Post 20 by @noahott — 2022-04-06T20:01:53Z Hey @ben, what to take a look at this thread again when you have a moment? I believe I have a working solution here now. Thanks! --- ## Post 21 by @ben — 2022-04-06T20:36:18Z --- ## Post 22 by @hallowichig0 — 2022-04-07T02:49:49Z This works for me :heart: Thanks @noahott --- ## Post 23 by @kellymears — 2022-04-07T10:44:34Z @aksld Do you mean that literally? As in: they are not enqueued by acorn? @noahott thanks for your work on this. two questions that could help me improve for future releases: 1. is it possible you could try playing around with this script? You would just replace `SEARCH_BODY_STRING` and `REPLACE_BODY_STRING` with `string` or `regexp` values. If you use a regexp it has to end with `/g` (global). ``` app.hooks.action('event.proxy.interceptor', async ({hooks}) => hooks.on('middleware.proxy.replacements', replacements => [ ...(replacements ?? []), [SEARCH_BODY_STRING, REPLACE_BODY_STRING], // can add as many as needed ]), ) ``` I think this hook will eventually be surfaced as an config fn – `proxyFindReplace()` or something to that effect. Curious if you would have been able to fix this with that as a tool, had it been available. 1. Related strongly to the first question… What is the value you are overwriting here? ``` app.hooks.action('event.server.after', async(app) => { Object.assign(app.server.connection, {url: new URL('http://theme.bedrock.lndo.site')}) }); ``` You can get at it with this snippet (run with `--log` flag and it’ll exit right after it logs the value): ``` app.hooks.action('event.server.after', async(app) => { app.log(app.server.connection.url).close() }); ``` :pray: --- ## Post 24 by @noahott — 2022-04-07T18:21:47Z 1. Your script also works to solve this issue for me. I set it up to find the URLs with port 3000 and remove the port: ``` app.hooks.action('event.proxy.interceptor', async ({hooks}) => hooks.on('middleware.proxy.replacements', replacements => [ ...(replacements ?? []), ['//theme.bedrock.lndo.site:3000', '//theme.bedrock.lndo.site'], // can add as many as needed ]), ); ``` 1. The value I’m overwriting is: ``` URL { href: 'http://theme.bedrock.lndo.site:3000/', origin: 'http://theme.bedrock.lndo.site:3000', protocol: 'http:', username: '', password: '', host: 'theme.bedrock.lndo.site:3000', hostname: 'theme.bedrock.lndo.site', port: '3000', pathname: '/', search: '', searchParams: URLSearchParams {}, hash: '' } ``` This is correct based on the default configuration, but causes an issue with Lando. The port used inside the docker container is 300, but should be 80 outside. When absolute URLs instead of relative, those assets don’t load. What I can’t figure out is why one of my projects includes vendor/app.js, vendor/bud.app.editor.js, app.js, etc. with relative URLs, while other ones use absolute. If we can ensure that relative URLs are always used, then this would not be a problem. Please let me know if there is any more info or help I can provide with this. --- ## Post 25 by @RistoKaalma — 2022-04-14T18:15:15Z Got it working, thanks @noahott ! Initially I did’t realize all `@Roots/...` devDependencies in `package.json` had to be updated to 5.7.7 for the whole setup to work. --- ## Post 26 by @RistoKaalma — 2022-04-29T16:55:58Z @noahott while on `theme.bedrock.lndo.site` don’t you have any issues logging into wp-admin (or alternatively to WooCommerce my-account)? In my case page reloads and fails to log in, no visible errors, nothing in console nor in debug log. --- ## Post 27 by @noahott — 2022-05-02T22:05:09Z Yes, this is an issue. WordPress is expecting it’s cookies to be set from the primary domain and I have not found a solution to this yet. --- ## Post 28 by @kellymears — 2022-05-23T09:25:02Z Recent versions of **bud.js** nulls the cookie domain which means you should be able to log in through the dev server URL. Assuming you are serving on `0.0.0.0:3000`: 1. Navigate to `http://localhost:3000/wp/wp-login.php`. Note that you must use `localhost`, the `0.0.0.0` IP will not work because it is not a hostname. 2. Clear application/cookie data. 3. Attempt to log-in. You will receive a UI error that cookies are not enabled in your browser. Ensure you are still on `localhost` and try again. 4. You should log in successfully. It may be more complicated here, depending on your setup and if you’re running `bud dev` from within the context of the container. I’m not sure. But the above instructions work for a VM with the `bud dev` command run on the host. --- ## Post 29 by @RistoKaalma — 2022-05-23T16:03:14Z Seems to be working for me. Thanks! --- ## Post 30 by @kellymears — 2022-05-24T09:48:59Z This got me thinking, though. Instead of setting the `domain` attribute to `null` what if instead it were just set to `undefined`? The answer is that it seems to make the login fully transparent in both directions. So, if you’re logged in on the proxied server that login is automatically applied to the dev server and vice versa. I opened a PR here: > > > Unsets the domain attribute for proxy cookies. > > Previously these were set as `…null`, which works. Setting them as `undefined` works, too. It just works _well_. > > Now, logins should persist between the dev server and the proxied domain. > > - none > > ## Type of change > > **PATCH: backwards compatible change** > > > > This PR includes breaking changes to the following core packages: > > - none > > This PR includes breaking changes to the follow extensions: > > - none > > ## Dependencies > > ### Adds > > - none > > ### Removes > > - none Going to ask a couple of other roots maintainers to give this a go before I merge it. I’m happy that `null` seems to be working, for now, and don’t want to mess it up :smiley: --- ## Post 31 by @cim — 2022-07-12T13:45:33Z Edit: moved to new topic as per request: [Yarn dev with Lando not working anymore (bud 6.3.0)](https://discourse.roots.io/t/yarn-dev-with-lando-not-working-anymore-bud-6-3-0/23548) --- ## Post 32 by @ben — 2022-07-12T16:22:41Z Please create a new topic relevant to your issue instead of bumping an old topic that was resolved months ago :pray: --- ## Post 33 by @ben — 2022-07-12T16:22:44Z