Breaking change in 0.15 - quasar builds absolute URLs in index.html

qyloxe

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>

qyloxe

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.

rstoenescu

Hi,

Are you aware of quasar.conf.js > build > publicPath ?
When building for PWA, you need to deploy at root and use the default publicPath, otherwise browsers won’t pick up the manifest.

Explaining the default behavior in detail takes a lot of time (which I don’t have), but it ensures you don’t do mistakes. Mind that you can build for SPA, PWA, Cordova, Electron. Each have their own particularities, especially when dealing with statics. Quasar CLI takes care of all the fuss and makes sure you don’t do mistakes. BUT it also allows you to set whatever publicPath you want when building SPA or PWA.

qyloxe

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”.

rstoenescu

If you are using vueRouterMode ‘history’ (are you?) then you can’t have publicPath set to empty string. Connect with me on Discord. The CLI automatically avoids some pitfalls for you.

qyloxe

@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)

rstoenescu

@qyloxe Someone getting what Quasar really is and what it stands for. I like it I just wrote a harsh comment on another thread which asked the question “What is the future of Quasar CLI now that we have vue-cli v3”. But reading this lightened up my day (well, it’s 2AM here, but still!).
Yes, I agree with documenting all the optimisations and work that Quasar CLI does for you (so you won’t have to), although docs are pretty complete as is (but don’t specify these “hidden” things). This would be nice as a blog entry or article. But there’s one catch. It takes time to write such an article and fully encapsulate all Quasar CLI does, while developers want more and more new functionality, bug fixes etc, etc. Currently spending time coding. Hopefully, after v1.0 (next major version after v0.15) things will settle more and I’ll have more time to write about significant implementation details so it can shed some light on what Quasar really is and to eliminate this feeling that “it’s just a component library”.

jeffatpf

@rstoenescu “after v1.0 (next major version after v0.15)…” - do you envision that the changes to v1.0 will be as disruptive as the changes from 0.14 to 0.15? Our application (projectfinance.io) is pretty robust and perhaps I hopped on the Quasar train a bit early, but It took me almost two weeks with some pretty pervasive code changes to move to 0.15.

No More Posting New Topics!

Breaking change in 0.15 - quasar builds absolute URLs in index.html