Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Expose history api fallback options

See original GitHub issue

Clear and concise description of the problem

We’re setting up a project simulating micro-frontend like qiankun in development, for this to work we need to respond index as a special “wrapper” html with qiankun runtime and a startup script pulling actual project, just like:

<script src="/__local_qiankun_bundle__.js"></script>
<script>
  qiankun.registerMicroApps([
    {
      name: 'xxx',
      entry: '/index.html', // The actual index html
      container: '#root',
      activeRule: '/',
    }
  ]);
  qiankun.start();
</script>

(This is only an example, actually we bundle qiankun runtime and entry script with esbuild.)

We then need to modify dev server’s route into:

history api fallback to /__qiankun_wrapper__.html which responds content described above
on /__local_qiankun_bundle__.js responds a bundled version of qiankun
/index.html to serve as what vite did not

Without the ability to customize historyApiFallback middleware, it is not possible to setup a server exactly do these staffs, and historyApiFallback is a special middleware that we cannot add another one before or after vite’s middleware array.

Alternative

Another solution is to allow a server.historyApiFallback: false option to intentionally disable history api fallback behavior, users can then add this middleware on demand.

Additional context

No response

Validations

Follow our Code of Conduct
Read the Contributing Guidelines.
Read the docs.
Check that there isn’t already an issue that request the same feature to avoid creating a duplicate.

Issue Analytics

State:
Created 2 years ago
Comments:12 (9 by maintainers)

Top GitHub Comments

3reactions

bluwycommented, Jun 26, 2022

Vite 3 can now officially support this with appType: 'mpa', which would disable the spa fallback, so you can add a custom one if needed via configureServer. appType is also used for the preview server too so it should emulate your production setup. Otherwise there’s also configurePreviewServer hook for plugins.

1reaction

chriscalocommented, Mar 9, 2022

I for one would love to see a built-in solution for this.

I came up with a very different plugin approach (see below), which seems to mostly work, though not perfectly[1].

Rationale for why this seems important to build into vite core:

Vite seems to take the stance that:

it’s a dev and build tool only, not to be used in production
built files are meant to be served statically, therefore, it doesn’t come with a production server

However, for static file servers:

in many static file servers it’s pretty easy to configure it to return index files when a directory is requested
however, they generally don’t fallback to serving /index.html when a file is not found and instead return a 404 in those situations

Therefore, it doesn’t make much sense that Vite’s dev server has this fallback behavior when it targets production environments that don’t have it. It would be nice if there were a “correct” (that is, well tested) way to turn off the fallback behavior while keeping the rest of the serving behavior (HTML transformation, serving the right headers, etc).

Update: I published the package vite-plugin-no-fallback to address this issue.

[1] The plugin above seems to have broken the ability to use a <script> tag with content as the app entry point instead of linking to the entry point via the src attribute:

<html>
…
  <script type="module">
    import Vue from 'vue';
    import App from './App.vue';
    
    new Vue({
      render: (h) => h(App),
    }).$mount('#app');
  </script>
…
</html>