@dobbel Ahh, thank you! That worked. The key was I needed to remove publicPath entirely from quasar.conf.js, not just set it to a relative path.

So, to recap for anyone else looking for an answer to this problem. If you want to build a quasar app such that the build can be mounted under arbitrary base paths, you need to:

1. Set vueRouterMode to ‘hash’
2. Set publicPath to null, or don’t set it all.

I may play around in my spare time with seeing if I can patch things up to get history mode to work with a relative public public path and post back here if I get something working.

@dobbel Ahh, thank you! That worked. The key was I needed to remove publicPath entirely from quasar.conf.js, not just set it to a relative path.

So, to recap for anyone else looking for an answer to this problem. If you want to build a quasar app such that the build can be mounted under arbitrary base paths, you need to:

1. Set vueRouterMode to ‘hash’
2. Set publicPath to null, or don’t set it all.

I may play around in my spare time with seeing if I can patch things up to get history mode to work with a relative public public path and post back here if I get something working.

@suleiman_as I tried putting this in quasar.conf.js

      vueRouterMode: 'hash', // available values: 'hash', 'history'
      publicPath: '.',

After running quasar build, index.html now has links like <script src=/./js/vendor.6e58a910.js>. Note the leading ‘/’ that quasar added. That’s because there’s code here
https://github.com/quasarframework/quasar/blob/dev/app/lib/quasar-conf-file.js#L41
that adds a ‘/’ to the front of publicPath if it doesn’t already have one, so you can’t set publicPath to a relative path.

I’m using @quasar/app 2.2.1. I gather from some old threads I found that some old versions quasar did support setting publicPath to a relative path. If you run quasar --version what do you get? Perhaps you’re using an older version?

@dobbel Thanks again. This still doesn’t seem to solve the problem though. I tried setting vueRouterMode: 'hash' in quasar.conf.js, and this has no effect on the generated index.html. It still contains script tags with absolute URLs, like <script src=/js/vendor.6e58a910.js>. So I still can’t take this build output and mount it under different base paths.

The issue you linked to also seems to be addressing a different problem: how to have static assets loaded from a different server than the one where index.html lives.

In case my original post wasn’t clear, let me restate what I want to accomplish.

I’d like to be able to configure a quasar app such that I can run quasar build once, and then take the build output from under dist/spa and deploy it to multiple servers mounted under different base paths. For example the app might be accessed on one server at https://example.com/, and on another server at https://example2.com/foo/.

Currently in order to deploy under multiple base paths, for each desired base path I have to run quasar build again with publicPath set to the desired base path, and then the generated app can only be deployed under the configured base path.

Thank you for your response. This is not the behavior I observe though. If I haven’t overridden publicPath, when I run quasar build, the generated index.html will have lines like <script src=/js/vendor.6e58a910.js>. Note the absolute path. This will fail to load if the app is deployed under https://myQuasarSPA.com/bar, because the script tag needs to be <script src=/bar/js/vendor.6e58a910.js> now for it to work. If I wanted the same index.html to work in either case, I’d need to change src urls to relative urls, like <script src=./js/vendor.6e58a910.js>. However, if I try setting publicPath to ‘./’, quasar changes it to ‘/./’. The only way I’ve discovered to make the app work with the /bar path prefix is to set publicPath to ‘/bar’ in quasar.conf.js and rebuild.

You can see the code responsible for this here:
https://github.com/quasarframework/quasar/blob/dev/app/lib/quasar-conf-file.js#L41
It simply won’t allow publicPath to be a relative path. This also affects vue router, since vueRouterBase is derived from publicPath.

I’m using quasar CLI 2.2.1. I’m trying to figure out whether it’s possible to build a SPA app using Vue router, so that it can be deployed under different base paths on a server without having to rebuild the app.

That is, I’d like to be able to copy the build artifact from quasar build under https://example.com/ on one server, and under https://example2.com/prefix/ on another server, and have it work either way.

As far as I can tell though, the only way to deploy under a path prefix is to set publicPath: '/prefix' in quasar.conf.js. I thought it would be possible to set publicPath to a relative URL, like publicPath: './', since Vue CLI allows that, but if I try that, quasar prepends a ‘/’ to it.

Is there any way to build a quasar app so it can be deployed under different prefixes, or do I just have to rebuild it for each prefix it’s deployed under?

Thanks

One slight disadvantage I found with using extends vs the solution I described initially above is that if you’re using an IDE, you lose autocomplete for component props, at least IntelliJ family editors. For example if I do

<q-input
   err<tab>

The editor will suggest the error-message, error and no-error-icon props, but when using my-input, I don’t get these suggestions. This could work in principle, but the Vue plugin for IntelliJ apparently doesn’t understand extends.

@dobbel I’m not sure I understand the Stackoverflow guy’s objections. I just tested out extends and it works. It may be true that you can’t “extend” the template code, so it doesn’t exactly correspond to subclassing in an OO language, which seems to be the Stackoverlow guy’s objection, but that seems like a fairly pedantic objection IMO. Extending solves the problem in this case. I just tested this and it works as expected:

// MyInput.vue
<script>
import { QInput } from 'quasar'

export default {
  name: 'MyInput',
  extends: QInput,
  props: {
    outlined: {
      default: true
    },
    dense: {
      default: true
    }
  }
}
</script>

I can use my-input just like q-input, and it supports the same props, events, slots, and methods. The only difference is outlined and dense default to true.

It was just pointed out to me in another thread that you can actually extend Vue components instead of wrapping them, which I think solves most of my concerns with wrapping. https://forum.quasar-framework.org/post/21630

Basically, instead of writing a wrapper like above, use extends like this:

<script>
import QInput from 'quasar'
export default {
  name: 'MyInput',
  extends: QInput
  props: {
    outlined: {
      type: Boolean,
      default: true
    },
    dense: {
      type: Boolean,
      default: true
    }
  }
 }
</script>

@jraez Thank you! I didn’t know about extend. That’s exactly what I wanted.

Just to help anyone finding this thread who wants the solution, I just tried @metalsadman’s solution for writing a QInput wrapper. This worked fine for a wrapper that overrides the outlined and dense props but otherwise has the same API as QInput.

<template>
  <q-input
    v-bind="attrs"
    v-on="$listeners">
    <template v-for="(_, slot) of $scopedSlots" v-slot:[slot]="scope">
      <slot :name="slot" v-bind="scope"/>
    </template>
  </q-input>
</template>

<script>
export default {
  name: 'MyInput',
  computed: {
    attrs () {
      return {
        // Put any prop value overrides here, before the ...this.$attrs line
        outlined: true,
        dense: true,
        ...this.$attrs
      }
    }
  }
}
</script>