boot files run twice... I need to comment in quasar.conf.js...

[sandroden]

Hi,

while debugging why a getter was declared as already present I realized that some of my boot files are run twice. Namely axios, auth and vuelidate. Commenting them in quasar.conf.js fixes the “double run” and each file in boot is called (but i18n and notifyDefault need to be named in quasar.conf.js to be called.

This all happened after I installed auth-token-based extension that (ta-da!!) installs or configure those boot files. Is there a way to implicitly call a boot file other than declaring it in quasar.conf.js, that I am not aware of? Do extensions do something implicit/magic with boot files? It seems pretty far from Quasar ultra explicit and clean way to declare boot sequence, but I can’t explain it in other ways…

Any hint is appreciated.

[s.molinari]

This is an interesting dilemma. For sure, an app extension shouldn’t add to what is already there in terms of boot file entries.

We’ll discuss this team internally and find a solution.

Scott

[sandroden]

Ok, thanks. In the meanwhile, I add some info to clarify my situation. The auth-token-based extension added 3 boot files, axios was already there and the extension prompted me to ask if I wanted to change or keep the original version. The app didn’t modify quasar.conf.js. I automatically thought I was supposed to add the ini files in the variable boot:

 boot: [
      // I see no reason why I should comment these boot file
      // but they are run anyhow and double run it is "evil"
      'i18n',
      // 'axios',
      // 'auth',
      'notify-defaults'
      // 'vuelidate'
    ],

just to discover that adding it manually made quasar complain that store getters and routes where already present.
So the first thing that puzzles me is: what is the mechanism that makes it run those boot file if not declared in boot array?
Currently, with axios, auth and vuelidate commented everything works correctly. They must be invoked by some mechanism I’m not aware of…

[s.molinari]

To get you to understand what is happening, have a look at the index.js file of the auth-token-based AE. Notice how the quasar.conf.js file is read and then the boot files are pushed to the boot entry. After that, Quasar starts doing its thing with booting up and thus, you get the double-loaded boot files.

Scott

[sandroden]

If I can dare add a newbie perspective, it would be nice if conf.boot.push('<name>.js') only added it if not already present. This way I could also decide a customized boot order. Probably better would be to write to quasar.conf.js at install time so that stays very clear which resources are called and used. This holds for components and directives as well.

[Allan-EN-GB]

Hey @sandroden,

We had a discussion about this but didn’t really come to a conclusion on it as such. Our stand at this point is this is something that should be handled in dev land (at least for the time being).

You made the point:

it would be nice if conf.boot.push(’<name>.js’) only added it if not already present

Well, this is what indexOf is for on an array. This is something in your control as a developer.

I would also go as far as saying that if your AE adds something in that Quasar offers as an option (i.e Axios boot) then you should prompt the user from your AE to ask if they want to install it or not. Failing that, rename your Axios boot file to something different if you need specifics in your AE.

We’re here to help if you have any issues with any of this.

[Hawkeye64]

The problem is, in the boot array, it can be named anything. For instance, axious.js or http.js or ajax.js and this would be an easy one.

[sandroden]

@Allan-EN-GB I understand that belongs to the devland, but since in no way there would be a benefit to run it twice, needing to force any AE author to check this would be not so clean. The conf.boot.push('axios.js') would never have any meaning if axios.js is declared in boot array. In my humble opinion, a function that takes care of checking if the file is already in the boot array and in case it is not, i adds it (ie: writes it in the quasar.conf.js) would make the boot process more clear.
Currently, it’s not enough to look at the boot in order to know what will be fire, you need to know each installed extension. That said, this is just the opinion of a quasar enthusiast that needs to practice more with this great game!

[Allan-EN-GB]

@sandroden Hi!

I completely understand your point of view and I share a similar one - there are however other factors that we’re taking into consideration as a team. That being said, this discussion is still taking place this morning in our team chat so while our official stance at the moment is handle it in dev land - I can’t say how the future will be on it