Well, I would love to see an organized page with many such lightweight quasar components. Similar to:

https://bootsnipp.com/

Bootsnipp had a tremendous impact on bootstrap popularity. I think almost everybody here has some interesting “components” or snippets of quasar code worth sharing.

@cst_zf it is based on HTTP header - user agent. In nginx there are at least two modules supporting detection of OS, browser, version etc.

In OpenResty (I prefer this solution) such a task is trivial because you have all the power of LUA scripting at the proxy level and you can do … anything.

@cst_zf said in Why there are two themes to choose during the building process?:

@a47ae if i want to show the websites material theme to android/pc visitors and ios theme to ios visitors, what should i do?

you can use reverse proxy (nginx/openresty/…) and with the same URI ("/index.html" in example), based on request headers (browser type) serve appropriate internal code ("/index_ios.html" or “/index_mat.html”). BTW using reverse proxy is almost always a preferred solution novadays.

@a47ae please read carefully and express yourself clearly. Seems “rude” or is “rude”? It’s a difference - similar to @Vinkman conception of similarities between Vue and Quasar. Quasar “seems” as “framework” or “component library” but in fact it isn’t, because it is much more than that. Analogously in my comment you feel “offended” but in fact this comment only defines the assumptions and “axioms” of discussion. In your comment you use a term “framework” but this definition is wrong, too. Why? Because frameworks works on client side, in spite to the definition of “library” they process and emit events. I just hope that you used that term metaphorically, because if you want to talk “engineering” you should be very precise with used terms. In the light of this, Quasar works and helps not only on the server side, but it helps with architectural design of the whole system. In example - if we will be talking about simple solutions, chat apps or similar, then we will never agree becasue we will have 1000s of possible of options for design and every single opinion would matter. But, consider this - you should create an architecture for application with federated logins, with potential of milions of users, with team of hundreds of people, with mixed backend servers, localised reverse proxy configurations, AWS etc. In such scenario, your path of possible solutions will be really thin. Would your actual understanding of the “framework” be “right” or “sufficient” for this discussion? This is not rude, this is just different level of discussion. The level based on engineering, architecture, true/false and not on @Vinkman or @a47ae feelings. That’s why quasar could be one of the biggest “gamechangers” in modern software ecosystem. We saw such events before and we will see them in the future. There were PHP/dynamic pages, there were XMLHTTP and SOA, there were microservices, there were virtualization - but - there were jQuery also and webpack. Every single mentioned technology changed minds. Quasar changes minds too, so please, do not think about it in terms of what already was.

@Vinkman as I understand your frustration it is based on following assumptions:

1. Vue is just a “better javascript” and it feels good
2. Quasar is just the “better Vue” therefore it should feel “more good”
3. Vue packaging/build concept is mature, well thought, good fit for everyone, and Vue is a “white” magic, which should handle everything for everybody
4. Quasar packaging/build is “black” magic, which does something supposedly useful sometimes for somebody, but it is not clear what, why and who
5. Writing “application” is inherently tied only with one developer framework, and every other person in the team responsible ie for deployment, qa, vision, integration, marketing, life cycle, should use their own solutions, because this one developer wants to “feel” good working with his beloved “framework”
6. Application plugin system is the same as architectural components of the final solution.
7. Design of final application should be managed only by a said developer, who is entitled to “feel” good.

Every single one of the above is false BTW.

@rstoenescu said in Breaking change in 0.15 - quasar builds absolute URLs in index.html:

If you are using vueRouterMode ‘history’ (are you?) then you can’t have publicPath set to empty string.

I think, that you are right not only with this answer, but rather on the fundamental, archetypical level of your design decisions. Why? Well, I didn’t know for example about connection to router etcetera, but this architecture, which is a “child” of yours imagination, just works together with itself and with many, many external designs, which sooner or later will be integrated. So, “my” solution with copying dist files into arbitrary folder was fine for me, even nice and useful, BUT it wasn’t the “right” solution. So, as for now, I have “proper” configuration, with “valid” support from DNS, the paths are set as you (I hope) envisioned, and suddenly - all is better. Well, I like such moments of enlightement ha ha but I think, that many of this subtle architectural decisions and paths should be documented somewhere. Maybe in documentation, maybe as “good practices”, maybe as smaller or bigger examples of real world apps (demo). I can see, that quasar is bigger than any of us could imagine. Congrats! (and it will be even bigger with drag’n’drop support ha ha)

Maybe you can set up a reverse proxy serving single html pages from SPA on the backend. Well, that would be a wild configuration.

Yes - the publicPath is the bad one. If I set it to specific folder then - lets assume, that it works as expected, it prefixes some scripts and css files in index.html. BUT if I set publiPath to “” then I expect it to NOT PREFIX anything (which allows me to just copy the dist folder to www struct anywhere - as it was in previous versions of quasar). Instead - when publicPath is set to “” then quasar (?) sets it to “/”, using it as prefix in scripts and css files, and I have to put all the files in dist folder in the main root of the website. Which is not always convenient, and in my specific situation broke test environment.
Well, as for now, we migrate tests to some DNS juggling, because of this change, but I assume, not everybody has access or knowledge to properly configure DNS servers - thats why I wrote harshly - sorry - “breaking change”.

Another piece of the puzzle:
there is an option in build property in config:

publicPath - String - Public path when deploying

BUT - setting it for example to “/build20180226/” wont change every generated link - for example in pwa manifest ignores this setting. So your application would break somewhere also.

Ideal solution would be to set publicPath: ‘’ - BUT - in this case, it is automagically converted to “/” and I think it is this autochange to “/” which breaks default builds.

After “quasar build”, in dist folder is generated main index.html file. In previous versions of quasar, all links to .js/.css files etc. were relative. Now, those links are absolute and prefixed with “/”.
Why is it annoying? Because before, we could just copy files from dist folder anywhere in the www server folder structure (for example: my.app.com/app1/build20180226/), and now it is presumed, that those files will always reside at myapp.com/. Maybe, there is build option which could change that, but unfortunately I haven’t found it yet. If it is, please help.

Example index.html with new “bad” absolute urls (my feelings are humbly expressed in comments):

  <!DOCTYPE html>
  <html lang=en>
     <head>
        <meta charset=utf-8>
        <meta name=format-detection content="telephone=no">
        <meta name=msapplication-tap-highlight content=no>
        <meta name=viewport content="user-scalable=no,initial-scale=1,maximum-scale=1,minimum-scale=1,width=device-width">
        <title>mytitle</title>
        <base href=/ > <!-- here is set an absolute base for all URLs - why?!!?!? -->
        <link rel=icon href=statics/quasar-logo.png type=image/x-icon> <!-- those links are generated OK, they're relative - BUT with that base href they're effectively not -->
        <link rel=icon type=image/png sizes=32x32 href=statics/icons/favicon-32x32.png>
        <link rel=icon type=image/png sizes=16x16 href=statics/icons/favicon-16x16.png>
        <link rel=prefetch href=js/0.726cd2bb82b222536118.js as=script>
        <link rel=prefetch href=js/1.1e0f2f247583830eac1c.js as=script>
        <link rel=prefetch href=js/2.2ff252f2f6dad888daab.js as=script>
        <link rel=preload href=js/vendor.f87be6de8670963f2179.js as=script>
        <link rel=preload href=js/app.7ee372648023dbb65d13.js as=script>
        <link rel=preload href=app.07f49f36db17576c4d52746152bea461.css as=style>
        <link rel=preload href=js/manifest.f82e3fcbfbf5c3f6126b.js as=script>
        <!-- another surprisingly absolute URL - ugh! -->
        <link href=/app.07f49f36db17576c4d52746152bea461.css rel=stylesheet>
     </head>
     <body>
        <noscript>
           <h3><!-- localised info about no javascript--></h3>
        </noscript>
        <div id=q-app></div>
        <!-- and now a bunch of horribly absolute URLs -->
        <script type=text/javascript src=/js/manifest.f82e3fcbfbf5c3f6126b.js></script><script type=text/javascript src=/js/vendor.f87be6de8670963f2179.js></script><script type=text/javascript src=/js/app.7ee372648023dbb65d13.js></script>
     </body>
  </html>