JS files loading too late in the build process

[shilman80]

I am trying to get nate-strauser:x-editable-bootstrap working with nemo64:bootstrap. nate-strauser:x-editable-bootstrap uses mizzao:bootstrap-3 by default and it works fine.

However, when modify it to use nemo64:bootstrap instead, it throws the exception $.fn.popover.Constructor.DEFAULTS undefined in the following code:

    $.extend($.fn.editableContainer.Popup.prototype, {
        containerName: 'popover',
        containerDataName: 'bs.popover',
        innerCss: '.popover-content',
        defaults: $.fn.popover.Constructor.DEFAULTS, <=== UNDEFINED

$.fn.popover.Constructor.DEFAULTS is eventually defined. Unfortunately it happens later in the loading sequence.

I read through the Meteor docs and Meteor github issue and tried playing around with the location of the javascript files on the client, e.g. /packages/bootstrap/bootstrap/js/*.js to see if I could force them to load earlier. Unfortunately, no luck. (mizzao:bootstrap-3 adds them in /packages/mizzao:bootstrap-3/bootstrap-3/js).

I'm wondering if you have any ideas or suggestions for how to get this working?

Many thanks!

[shilman80]

In a fit of desperation I have tried the following:

1. Copied out the files bootstrap/js/*.js from nemo64:bootstrap-data into client/lib/bootstrap/lib/*.js
2. Renamed transition.js to 0_transition.js and tooltip.js to 1_tooltip.js to force earlier loading
3. Copied out the files *.{js,css} from nate-strauser:x-editable-bootstrap into client/lib/bootstrap-editable/*.{css,js}
4. Verified this configuration loads properly (after trying various other configurations that did not load properly).

Then I:

1. Modified nemo64:bootstrap to write the *.js into that same location client/lib/bootstrap/lib/*.js.
2. Observed that this setup gives me the same loading error as before.

Would appreciate any insights you might have. Otherwise, I'll probably need to go with a different solution for configuring my bootstrap. 😦

[Nemo64]

Well, meteor loads all packages in the order defined in the .meteor/packages so your problem probably is that the bootrstrap package is defined after the x-ediable-bootstrap package.

[shilman80]

Thanks for getting back to me. :) Hmm. I should have mentioned that bootstrap was imported before x-editable bootstrap in .meteor/packages -- one of the first things I made sure of.

For now I have x-editable-bootstrap working with a forked version of mizzao:bootstrap-3 that doesn't insert CSS, so I can still configure my LESS as if I was using nemo64:bootstrap. However, I am not happy with this hard-coded solution, and would love to get nemo64:bootstrap working.

I am happy to set up a stripped down sample repo if you have time to take a quick look at it?

[Nemo64]

I think I already know where the problem is.

I include the javascript while processing the json file. The problem is that meteor internally "thinks" that this json file is a bunch of javascript. That means the bootstrap javascript gets loaded when your code is loaded (after all packages). So the current solution makes it impossible to have a package thats hard dependent on bootstraps javascript.

[shilman80]

Ugh. That seems like a pretty significant issue with this package and/or Meteor's internals.

Would it be possible to read in the nemo64:bootstrap JSON configuration in the plugin's onUse step and then perform all the logic there? Or is the current way the only way to get "called back" when the config file changes?

[Nemo64]

It is sadly the only way of even accessing a file during the build process but the behavior is technically correct. Meteor lacks a default way for configuring packages, that would be the right way to go.

[shilman80]

Did you consider configuring via settings.json? https://docs.meteor.com/#/full/structuringyourapp

[Nemo64]

Wouldn't work either. The problem is that i need a hook to tell meteor to include files depending on the configuration. The build plugin is the only hook i know of, which allows to dynamically create js/css and include it into the app. But at that point where the build plugin starts, it's already to late to include files before packages do.

[Helmi]

Just wanted to follow up on this - didn't anyone yet find a solution for that? We're on the same boat with x-editable here but basically bootstrap js-dependencies might even be a problem in other cases in the future...

[hamoid]

One hour trying to figure out why hinas:meteor-bootstrap-confirmation stopped working after I installed nemo64:bootstrap. I leave this comment in case it happens to someone else.

[hamoid]

It seems like the only way to customize Bootstrap, and have it's assets be available for other addons, is to build your own Bootstrap package. It's less hard than it sounds. I modified this script for that purpose: https://github.com/mizzao/meteor-bootstrap-3/blob/master/update.sh

[ChrisCinelli]

They should have a way to define loading order. If you start a project from scratch it is not a major problem but as soon as you try to convert a older project you end up spending more that you should.
How difficult would it be to have a configuration variable where you can specify the file order in a javascript object or an array?