Spot the difference? One package version build that works, and one that doesn't?

help
1

Hi!

I got this baffling problem. I’m using the package Accounts-T9n with a Meteor 1.0.5 app. I’m using several other packages. I’m trying out two versions of Accounts-T9n: 1.0.6 and 1.0.8. Now with everything else constant and I do a meteor build for each version (I switch between the two by editing the .meteor/versions file), and do a Phusion Passenger deployment, the one with 1.0.6 works fine. The one using 1.0.8 keeps on triggering an infinite browser refresh loop just when the data is about to finish loading. I can’t see any error messages dumped into the console either.

This only happens on a meteor build deployment. Meteor @ Localhost appears to be fine.

I’m looking through the difference between the two versions @ github here:

Would anyone know what’s going on?

2

It may be obvious and you may possibly already have tried that, but did you try changing the dependency versions on your packages and package.js files instead of the versions file? The new version resolver may be going nuts due to your manual override which you are advised against.

3

Hmm… where can I find the package.js file? I tried looking at the one in ~/.meteor/packages, but these look like some isobuild ones… They don’t resemble files like those from the author’s github page. I haven’t tried cloning the github package into the /packages directory and adding it from there yet. I only added using:

meteor add softwarerero:accounts-t9n
4

Ok, well, I tried clearing all accounts-t9n related packages old and new in ~/.meteor/packages forcing a redownload. Seems to be working now, but I’ll have to keep an eye on it.

5

Great.

Just in case, you can do $ meteor reset to clean your build dirs.

To check your versions, look at projectroot/.meteor/packages where you normaly include tha package in the format of author:package but you can also do author:package@v.v.v where you explicitly set your required version number.

The version solver checks that and the requirements from the other packages you have in your project.

If a package from your project requires another version, the solver tries to get the best one. If a package you use requests a version that you don’t want and also causes a problem, you can fork that package, include in your project manually and change its dependencies from that package.js file of that package.

6

Well, the problem didn’t seem to go away, and in fact, rendered my applying of v1.0.6 of that package useless (gave me that refreshing problem too). That was last night, so I just decided to throw in the towel, shut down everything and do a restart. Maybe something was screwed up then… I’ll see what happens now when I try to do a rebuild.

@projectroot/.meteor/packages - yah, this is what I touch, often when I do updates. I suppose my last ditch effort is to grab that package and put it in the projectroot/packages/ folder…

7

Hmm, do I have to do a meteor reset before I do a build?

8

Ok, I think the problem might be related to CloudFlare, since I have this enabled. I’m doing more observations to see what might be causing this (unless for every update I do for my app, I need to log into CloudFlare and purge the cache…)

EDIT: yep, that was it. Need to purge CloudFlare’s cache when updating the production build…

9

Are you deploying you app as a node app or a meteor app? If you are deploying as a meteor app, you need to pass in the --production flag.

I don’t know about Cloudflare cache though, if it is caching / it definitely does something wrong there. If not, then the production flag is what you may be lacking.

10

I’m running it as a node app using [meteor build].

11

In that case, whenever you update your build and redeploy, meteor changes the filenames of js and css files. That means, if there is a cache issue, it would be Cloudflare caching the domain root route / so you might want to check if there is an option to not cache that.

And once you’re done, you’ll be off good.

12

Yeah, it seems just manually purging the cache (or via the api) is the most practical thing to do now. I mean, we do like the fact that it caches the JS files, but we just want it to update its caches when needed. We can remove cache for individual files, but that’s not practical for a Meteor app hehe