Following dockerfile uses a 2 stage approach for building a quasar 0.15 app.
2 stage means that the first stage will only build the sources and stage 2 is for hosting the SPA in an nginx container.

# Build stage
FROM node AS buildenv

WORKDIR /generator

ENV projectName "MyQuasarProjectFolder"
# restore

# copy src

COPY ./${projectName}/package.json .
COPY ./${projectName} .
#RUN npm install -g quasar-cli

RUN npm install

RUN node node_modules/quasar-cli/bin/quasar-build

# Runtime stage

FROM nginx
ENV projectName "MyQuasarProjectFolderr"
COPY --from=buildenv /generator/dist/spa-mat /usr/share/nginx/html
COPY ./${projectName}/default.conf /etc/nginx/conf.d/default.conf

EXPOSE 80

The additional default.conf file is nginx specific:

# based on https://gist.github.com/szarapka/05ba804dfd1c10ad47bf
server {
    listen       80;
    server_name  localhost;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
        try_files $uri $uri/ @rewrites;
    }

    location @rewrites {
    rewrite ^(.+)$ /index.html last;
  }
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

}

@fabio Thanks. Note that " … please fix it !" is a kind of directive which is 100% incompatible with open source development.
Maybe what can help you is to imagine that the people reading your text are standing in front of you.

Apart from that, I think that both content and presentation of the documentation is extraordinary.

For quasar pre-V1, I was using an approach with docker to publish my apps.
for V1, this approach gave some issues. Maybe useful for other devs, so here is my new docker file:

# Build stage
FROM node:8 AS buildenv

ENV YARN_VERSION 1.13.0

RUN curl -fSLO --compressed "https://yarnpkg.com/downloads/$YARN_VERSION/yarn-v$YARN_VERSION.tar.gz" \
    && tar -xzf yarn-v$YARN_VERSION.tar.gz -C /opt/ \
    && ln -snf /opt/yarn-v$YARN_VERSION/bin/yarn /usr/local/bin/yarn \
    && ln -snf /opt/yarn-v$YARN_VERSION/bin/yarnpkg /usr/local/bin/yarnpkg \
    && rm yarn-v$YARN_VERSION.tar.gz

WORKDIR /generator
ENV projectName "my-project"
COPY ./${projectName}/package.json .
COPY ./${projectName}/yarn.lock .
RUN yarn
COPY ./${projectName} .
RUN node node_modules/@quasar/app/bin/quasar-build
# Runtime stage
FROM nginx
ENV projectName "my-project"
COPY --from=buildenv /generator/dist/spa /usr/share/nginx/html
# COPY ./${projectName}/default.conf /etc/nginx/conf.d/default.conf --> in case you want nginx specific conf

EXPOSE 80

Some remarks:

• I run into something very strange when i used npm (with quasar V1) on docker: npm didn’t pick up the latest quasar node_modules. So, that’s why i moved to yarn in the docker file.
• the docker file explicitely installs a version of yarn specified in the docker file.
• I needed to downgrade to node:8
• No need to install @quasar/cli in the docker container !

Please provide feedback in case you see potential improvements.
cheers

solved.
When implementing the beforeEach in a plugin, it works

export default ({ router, store, Vue }) => {
  router.beforeEach((to, from, next) => {
    console.log('before each')
    debugger
    console.log(store.state.example.test)
    next()
  })
}

http://blog.opinionatedapps.com/posts/a-pure-client-side-elastic-search-solution-with-vuejs/
(blog has link to sources).
demo: http://blog.opinionatedapps.com/ItemsJs-Vue-Demo/

cheers
paul.

@nothingismagick .
Thanks for this. Great work.
A lot of new things in this area when Vue v3 arrives.

I ran recently into same trouble with nginx when using child routes.
So main routes worked perfectly , but not routes with 2 params in it.
I’m using following nginx config:
location / {
root /usr/share/nginx/html;
index index.html index.htm;
try_files $uri $uri/ @rewrites;
}

location @rewrites {
rewrite ^(.+)$ /index.html last;

}

But the most important update i did was in the config.index.js file:
publicPath: ‘/’, for the PRODUCTION. section

Thanks. I proceed per your suggestion. Looking forward to all goodness in 0.14.

I want a screen based on common components that has a different layout when it’s run a small form factors.
More concrete on larger screens I want a screen that has 2 columns for visualizing master detail structure, left column is a list with master data, right column is the detail data.
On smaller screens I only want to visualize the master data (so, the left column but full screen) and a ‘row click’ should navigate to a dedicated detail screen.
I’m currently doing this with the javascript platform detection which I can use both the in the html and javascript.
So e.g. for the logic of the master/detail:
<div :class="{'col-4': $q.platform.is.desktop, 'col-12':!$q.platform.is.desktop}">
and inside javascript I can provide dedicated handling for a row click in the master list:

 projectItemClicked(item) {
      if (this.$q.platform.is.desktop) {
        if (!canSave) {
          this.selected = item
        }
      } else {
        this.$router.push({ name: 'OrderItemEdit', params: { id: item.id, parentId: this.parentId } })
      }
    },

This works nice but I’m evaluating another approach.
The drawback of the above approach is that I can only make distinction desktop/non-desktop.

• on large tablets I also get the one column layout
• when a destkop uses a small browser window, the layout is still in 2 columns.

I’m aware that flexbox could help here but I’m not understanding how exactly.
With flexbox I could make sure that on small form factors the 2 columns are transposed to rows. Not completely what I want because on small form factors I don’t want to see the second column.
How could I make logic decisions in javascript (as above)?
thanks for the guidance.
paul.

@Hawkeye64 solved. see: https://forum.quasar-framework.org/topic/2825/store-is-no-longer-accessible-in-router/4
Thanks for the help.

https://storybook.js.org/docs/guides/guide-vue/

For a vue-cli app following plugin works like a charm:
https://github.com/storybooks/vue-cli-plugin-storybook

Unfortunately, I’m using quasar-cli…