Hi, I’m trying to use http://0.0.0.0:8080 in proxy but when I run yarn dev, it shows http://0.0.0.0 instead of http://0.0.0.0:8080
1 Like
Please provide code showing how you are trying to do this. Very difficult to debug without code.
Have you tried the instructions in the bud documentation? https://bud.js.org/guides/general-use/dev-server#proxying-an-existing-server
Hi @alwaysblank,
I don’t know if this is a bug but when I tried to use other ports like http://localhost:8000, the proxy was showing the correct port. It looks like all ports were shown as expected except the http://localhost:8080.
Here is the screenshot of using other port (http://localhost:8000):
As you can see, the proxy was showing the correct port.
Here is my bud.config.js:
/**
* Build configuration
*
* @see {@link https://bud.js.org/guides/getting-started/configure}
* @param {import('@roots/bud').Bud} app
*/
export default async (app) => {
// console.log(app.hooks.all());
app
/**
* Application entrypoints
*
* Paths are relative to your resources directory
*/
.entry({
app: {
import: ['@scripts/app.js', '@styles/app.scss'],
publicPath: '/app/themes/example-theme/public/'
},
editor: {
import: ['@scripts/editor', '@styles/editor'],
publicPath: '/app/themes/example-theme/public/'
},
})
.provide({
jquery: ["jQuery", "$"],
})
/**
* These files should be processed as part of the build
* even if they are not explicitly imported in application assets.
*/
.assets([
{
from: app.path('@src/images'),
to: app.path('@dist/images'),
},
{
from: app.path('@src/fonts'),
to: app.path('@dist/fonts'),
},
])
.runtime(false)
.splitChunks(false)
/**
* These files will trigger a full page reload
* when modified.
*/
.watch(["resources/views/**/*", "app/**/*"])
/**
* Target URL to be proxied by the dev server.
*
* This is your local dev server.
*/
.proxy('http://localhost:8080')
/**
* Development URL
*/
.serve('http://0.0.0.0:3000');
// app.log(
// app.hooks.filter('build')
// ).close()
};
By the way, I’m using sage tag v10.4.0
Even I tried this yarn dev --proxy http://localhost:8080
It’s still showing localhost instead localhost:8080
Does the URL work if you visit it? I.E. HMR works as expected, etc.
There might be a bug in Bud or something that can be improved to support this, but I’d really suggest just using a regular hostname instead of localhost (and without a port), like example.test.
1 Like
Nope. I got " This site can’t be reached" because the proxy gave me localhost instead of localhost:8080 but using other ports is working fine.
Had the same problem. looking into the bud source it seems that the ports 80 and 8080 get replaced with an empty string. This happens in @roots/bud-dashboard/lib/dashboard/server/parsePort.js.
/**
* Parse port and return as a string with `:` prefix
*/
const parsePort = (port) => {
if (!port ||
(isString(port) && [``, `80`, `8080`].includes(port)) ||
(isNumber(port) && [80, 8080].includes(port)))
return ``;
return `:${port}`;
};
Confirmed that this is causing it by removing the early return. Not sure why this was added. But this feels like unwanted behaviour for giving in a proxy url. Not knowing bud internals this might be done as it’s needed somewhere else in bud when parsing a port.
The dashboard is purely presentational. When you call bud.proxy and pass in a string or URL that object is passed on directly to the proxy middleware. The only context the port is formatted in is for presenting to the developer in the CLI.
Conventionally, I would expect port 8080 to be mapped by nginx or apache or whatever to the public port 80.
Specifically, it’s common to be using http://localhost:8080 in a docker container and mapping that port to 80 on the host machine. This is referenced directly in the docker documentation:
If a docker user with a similar setup clicks http://localhost:8080 they will get a 404 because the host machine isn’t running anything on port 8080.
So, clicking the URL is going to 404 for someone, and right now I’m assuming it’ll 404 for more people if there is no handling done given how common this setup is for containerized development environments.
This PR is relevant to this discussion:
If it’s merged the dashboard informational display will work as you expect it to and users who access their site via a different URL than it is served from will need to specify it in their configs:
export default async bud => {
bud
.serve(8080)
.setExternalUrl(`http://example.test`)
}