Load Order of Assets


#1

I am really struggling with the load order of files in Meteor. I have resorted to creating my own application-specific package that loads a whole unch of packages that I want to include in my project, e.g. a specific version of JQuery, JQuery UI, Bootstrap, etc. I have done this because it seems the only way to be able to force a load order on things that depend on each other and that doesn’t use public packages that are only one specific release version and still allows Meteor to auto combine and minify my CSS/JS. Is this really the only way to d this?


I dont get it; or the DAG of Meteor
#2

Well the best way to handle this would be to create packages out of the code that is being depended on, then add the package into your project. This gives you the ability to control load-order precisely.


#3

Load order within one package is alfabetically. So you could rename your assets to:
10_jquery.js
20_bootstrap.js

Or, as you describe, create packages and set dependencies.


#4

That’s good to know hat I am going about this the right way.


#5

I think load order can be quite confusing at times, so I created a small little app that helps you understand it much easier. You can check it out here: https://github.com/meteorinaction/ch11-isobuild/tree/master/load-order (it’s only part of the repo, so you need to clone the entire ch11-isobuild repo in case you want to run it).


#6

in general you should aim for a approche where load order is not importanted
you can use Tracker for dependencie tracking or session var etc
because just if a file is loaded it is not ready so you can still run into error.


#7

I am struggling to visualize how an application can not have assets that depend on each other, jQuery dependencies being the most basic example of this. In addition, you may also want to override code in a package, e.g. Bootstrap styles.
How can both of these examples be managed other than through managing the load order?


#8

@lampe is right. If you use the Meteor APIs properly, load order won’t really matter for the most part. You should run your entrypoint logic in Meteor.startup(), then that code always runs after all files have been loaded. Avoid libraries that depend on other libraries at runtime without you calling any API, then you yourself call APIs inside a Meteor.startup callback.

Theoretically, Bootstrap shouldn’t call any of jQuery’s APIs until you call one of Bootstrap’s APIs, in which case load order won’t matter. If Bootstrap is calling jQUery APIs prematurely, that is bad.


#9

@trusktr Would you be able to point me in the direction of some useful examples/documentation about how to use the Meteor API’s properly? Could you also give an example of what ‘entrypoint’ logic is and how to place it in the Meteor.startup() function? Also, how do I avoid libraries that avoid other libraries and how to call API’s inside a Meteor.startup callback ?


#10

@tidee

Meteor.startup(function() {
  // Code goes here. This is your entrypoint.
}) 

If you meteor add twbs:bootstrap you don’t even have to worry about these problems. Adding the twbs:bootstrap package will cause the jquery to be added also, and they will both work.

You can also use something like webpack to manage module loading instead of relying on Meteor’s load order.


#11

I created my own package loader because I wanted specific versions of bootstrap/jquery in my application and was afraid that whatever someone else packaged up wouldn’t play nicely with other packages that required a different version of jquery, for example. Any thoughts on how to managed package version control within my app?


#12

I’m actually creating a solution for this right now. I am planning to release it next week. It uses webpack behind the scenes to allow any Meteor package to get client-side libs from npmjs, and will automatically handle shared dependencies across packages. You’ll be able to get any version of bootstrap with it for sure.

I think it’ll be meteor add rocket:module. :smile: Check WIP here.

The benefit of my package will be that (1) you won’t have to wrap non-Meteor libraries as Meteor Packages just to use them and (2) all of your code can be CommonJS or ES6 Modules.


#13

404 error
moved to here it seems