@bibogold - maybe I didn’t understand your issue completely. I can say though that my individual navigation guards on each route do what you want - they check whether the user is logged in or not, and if not, they do a redirect to a login page:

…
component: () => import("…/pages/my-quasar-component.vue"),
beforeEnter: (to, from, next) => {
if (globalStore.state.userNotLoggedIn) { // this is my own store which holds login state
next({ name: “LoginRoute” }); // redirect to login route (per route name)
} else {
next(); // grant access to route/component
}
}

@tof06 - thanks for that hint, it looks like I misunderstood that template. I added the uglifyOptions now in front of that env: in the build section, and with a fresh build on Heroku, the console.logs are gone, so that problem is solved.

Unfortunately I get another problem (CORS error on some of the requests from the Quasar frontend to the backend) with that build. I still have to diagnose whether it is a side effect of the drop_console or a separate problem.

I can’t tell what you’re problem exactly is, but I initially tried to implement a global route guard for my routes as well, and had lots of issues with it.

I changed my code to have individual route guards (with a separate beforeEach (to, from, next) on each route) instead of the global route guard, and that works without issues, though it duplicates some of the code.

Thanks, I tried your suggestion, but still get console log output.

My quasar.conf follows the official template from the Quasar docs on https://quasar.dev/quasar-cli/cli-documentation/handling-process-env#Adding-to-process.env

Afaik, process.env is the same as ctx.dev, which is true for a dev environment and false for a prod environment. So it should set drop_console to true in a prod environment.

Still not sure why it doesn’t work.

Gentle reminder: Anyone who knows how to get rid of console.logs in production?

@Allan-EN-GB
Sorry, I have problems getting removal of console.logs in production working: Based on the answer to this StackOverflow post, I added to my quasar.conf the following:

build: {
  env: ctx.dev
  ? {
     // son dev we'll have
     // some settings for dev here...
     } 
   : {   
     // and on  build (production)
        uglifyOptions: {
          compress: { drop_console: true }
         },
      // some other prod settings go here...
      }

After doing a successful production build and deployment (on Heroku), I still see all console.logs statements from my Quasar app in the browser console.

What could be wrong with my approach?

Wow! I was not aware of this width: x% parameter. It is not used widely in the docs. Thanks!

I have a simple question for which I did not find an answer in the docs or the forum:

If I have two q-btns positioned vertically within one column, like:

            <div class="col-2">
              <q-btn
                label="Short label text"
              />
              <br />
              <br />
              <q-btn
                label="Looooooong label text"
              />
            </div>

How can I achieve that those two buttons get the same width (either that both have the same, fixed width, preferably large enough to fit the longer label text on button 2, or both stretch out to the full column width)?

I found in older Quasar docs that an early version of Quasar supported a “stretch” prop for q-btn, but I don’t find that in the current API docs.

After realizing that Heroku as the deployment environment for my Quasar app has restrictions with uploading/downloading of files, I’m now looking for some sample code how to use q-uploader to upload files to Amazon S3..

I’m not familiar with S3 yet and have used q-uploader so far only in a simple way, to upload files to the file system of the Quasar frontend app.

All I found so far as a boilerplate to start from is a tiny code snippet on the old Quasar site (https://forum.quasar-framework.org/topic/5382/how-to-use-q-uploader-in-quasar-app-deployed-on-heroku ) that uses q-uploader with so called signed S3 URLs.. It uses a q-uploader prop :url-factory=“getSignedUrl”, but I can’t find that prop in the API documentation of the current version of q-uploader on https://quasar.dev/vue-components/uploader#QUploader-API.

Is there another sample or Codepen how to use q-uploader to upload a file to Amazon S3?

Would greatly appreciate some advise.

Isn’t there anyone out there who has experience with deploying a Quasar app on Heroku?

Meanwhile, I did some further reading, and I’m led to believe:

• Starting two Node processes in one Heroku dyno as I tried it with the start script above is probably not supported by Heroku…at least it ignores that “node file-uploader.js” after the “&&”

• There is another serious restriction with Heroku that I was unaware of: Heroku restarts each dyno once per day and wipes out all uploaded files - therefore file upload as I have implemented it for local deployment won’t work on Heroku.

• To deal with that, Heroku docs recommend to upload files to Amazon S3, not Heroku. So I will have to adapt my q-uploader code to upload to S3, and deal with file URLs from S3 to download files from there (currently those are simple frontend file system URLs used in simple href links). Alternatively, I could store them in my MongoDB backend database, but that seems to be even further away from my current setup.