Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: allow backend custom host #918

Merged
merged 1 commit into from
Oct 20, 2020
Merged

feat: allow backend custom host #918

merged 1 commit into from
Oct 20, 2020

Conversation

edersoares
Copy link
Contributor

@edersoares edersoares commented Oct 16, 2020

This PR allow to serve the frontend by Vite through a custom host in backend.

Running backend at https://laravel.test, frontend at http://localhost:3000 and a view in backend like this:

<body>
  <div id="app"></div>
  <!-- This will be injected only for dev mode -->
  <script type="module" src="http://localhost:3000/vite/client"></script>
  <script type="module" src="http://localhost:3000/src/main.js"></script>
</body>

This will allow that a different backend host, connect to Websocket correctly #460.

Context:

Instead of get the host info from browser https://laravel.test, Vite will get from your own host/port http://localhost:3000.

Limitation:

It's necessary to use this approach #341 (comment) to add CORS into Vite server.

// vite.config.js 

const cors = require('@koa/cors');

export default {
  configureServer: function ({ app }) {
    app.use(cors({ origin: '*' }));
  },
};

And the backend will need to have a symlink in public folder to serve assets/static files correctly because relative paths will have base URL from backend now, something like this:

/backend
  /public
    /assets -> ../vite-project/src/assets
    /index.php

Fixing partially #341.

Credits:


Update 19/01/2021

For Vite 2.0 is needed change script URL injected in backend view to http://localhost:3000/@vite/client:

<body>
  <div id="app"></div>
  <!-- This will be injected only for dev mode -->
  <script type="module" src="http://localhost:3000/@vite/client"></script>
  <script type="module" src="http://localhost:3000/src/main.js"></script>
</body>

And assets symlink will be changed to:

/backend
  /public
    /src -> ../vite-project/src
    /index.php

@@ -1,7 +1,7 @@
// This file runs in the browser.

// injected by serverPluginHmr when served
declare const __PORT__: number
declare const __HOST__: string
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should keep the __PORT__ and let __HOST__ fallback to the original behavior.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@antfu the original behavior was introduced in rolldown@bb18db2

The new behavior is another way to do samething, but instead of get hostname and port from browser, it will get from directly Vite server.

In old behavior ${socketProtocol}://${location.hostname}:${__PORT__}, location have context from browser.

In this new behavior ${socketProtocol}://${ctx.host.toString()}, ctx will have context from Vite server.

I think that we can revert rolldown@bb18db2 and just let this behavior.

What do you thing?

@underfin underfin merged commit bec6b3c into vitejs:master Oct 20, 2020
@edersoares
Copy link
Contributor Author

When you access the backend host, the assets/static limitation can be treated by:

// vite.config.js

const cors = require('@koa/cors');

export default {
  configureServer: [
    ({ app }) => {
      app.use(cors({ origin: '*' }));
    },
    ({ app }) => {
      app.use((ctx, next) => {

        // ensure that URL not be http://localhost:3000/localhost:3000/src/assets/logo.png
        // when requesting assets/static by frontend host
        ctx.request.url = ctx.request.url.replace(`/${ctx.hostname}:${ctx.port}`, '');

        return next();
      });
    },
  ],
  vueTransformAssetUrls: {
    base: 'http://localhost:3000/src/',
  },
};

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants