I have created a custom NPM package that I am trying to reference from my Meteor module. However, the version being pulled by Meteor is NOT the version I have specified–but an earlier version.
How can I clear the cached used by Meteor, so the correct version can be pull from the NPM repository. I have only ONE version available in the repository, but Meteor seems to refuse to pull it. Instead it continues to reference a version that does not exist any longer.
HELP!
Do you have a reproduction? I’d like to try running this code.
Is your new version a major version upgrade as in v 1.0 to 2.0
Thanks for the quick replies and requests for reproduction. As it turns out, I found the answer, which turned out to be a simple mistake. When packages are generated, there is no “.gitignore” with them. The modules referenced were checked into a public “Github” repo, so they could be registered for use with “Npm.depends”, which requires that a module be named and of a specific version registered with NPMJS.org.
You have a SINGLE opportunity to registered a name/version pair with NPM, and a cached version of your repo ends up on their server. This prevents dynamic updating from your Github repo directly, which presumably prevents developers from ever getting an unexpected version of a component.
The problem is that Meteor provides no way to directly reference a Github repo during development, so if there are bugs are mistakes in your repo, you constantly must update all the associated references to NPM modules AND their Meteor wrappers.
Simply put, I had a version of ONE NPM module that had, by mistake, include the “node_modules” directory that contained an OLD version of one of the other referenced components. I was dead in the water from then on, and due to how NPM modules are imported in Meteor’s “Npm.depends”, the error was almost impossible to find, resulting in my frantic message here.
A simple fix that would probably help everyone would be to provide a way during development to use Github repos directly instead of having to register unfinished, broken components with NPM and have to manage all the potential version conflicts inside wrappers.
Can this be done?
That’s a good idea, I wonder if it would be possible. I think it would make having binary builds for different platforms difficult.
I found this post after an update to my meteor/npm wrapper wasn’t working. Turns out that I had the ‘local’ version cached, and clearing .meteor/local/plugin-cache/mymodule/local fixed it. Might help someone else who finds this post.