Ok this time it was clearly my fault, because I was missing a semicolon in the package.json.
Regarding to this problem I wanted to ask, is it possible to print out the related json file in the console to make it easier to find the cause in future versions?
My main problem was the one with the “Collections-Object” and I feel like something has changed in the loading order within meteor projects.The imports of the collections occur before the initialization
This is the structure of my project. Files in /server are now executed before files in /collections
import Collections from '/collections/collections';
import Schemas from '/collections/schemas';
Collections.Notes = new Mongo.Collection("documents.notes");
Schemas.Notes = new SimpleSchema({
name: {
type: String
}
});
Collections.Notes.attachSchema(Schemas.Notes);
Collections.Notes.allow({
insert: function () {
return true;
},
remove: function () {
return true;
}
});
export default Collections.Notes;
In the documentation it says that modules in the /imports directory have to be imported to be loaded explicitly. If I only import the collections.js it seems to be clear that the actual collections aren´t loaded with it, so it seems that using the imports directory is not the right way for the collections object approach.
Moving /collections to the projects root doesn´t work anymore.
Hi, after I updated my project it crashed because I do not have babel-runtime in dependencies of npm. I just run meteor npm install babel-runtime --save and everything went ok.
I have not found this information on guide and I think this can be useful there.
I know this is at the changelog but if it was on the guide it would avoid any misunderstanding.
I had some problems doing this migration. This was my process for upgrading:
I first updated npm to 5 meteor npm -g install npm
Then I guess I run a meteor npm update
this gave me some warnings, which I ignored.
Then I tried meteor npm -g update
which did’t work at all
Then I proceeded to run a meteor update --all-packages
which proceeded to break everything, when I started tracing the errors it looked like some trouble with the accounts package, after downgrading every package that meteor updated in step 3 to the version I had before the update, I still got the same error.
Now also when I tried to run meteor npm update it gave an error about npm.
After this I proceeded to uninstall meteor, install meteor, create a new meteor project, migrate my app to this new project (I don’t know how to reset the local folder, I once deleted it and it broke, so now to reset my project I create a new empty meteor app and migrate my code plus install any meteor packages I need).
Now when everything was working again, I run: meteor update --all-packages
Everything in meteor gets updated, I have now Meteor 1.5 and everything works.
The thing is I want to upgrade meteor’s npm to 5 with meteor npm -g install npm but I’m not sure if its safe to do so or if meteor updates it bundled npm at some point and I should just wait.
Right now when I run meteor npm ls I get this error: npm ERR! extraneous: rimraf@2.6.1
and if I run meteor npm -g ls I get these:
npm ERR! peer dep missing: babel-runtime@^6.22.0, required by babel-preset-meteor@6.26.0
npm ERR! missing: nopt@2 || 3, required by node-gyp@3.6.0
npm ERR! missing: nan@~2.2.0, required by sqlite3@3.1.3
Meteor 1.5 is not setup to work with npm@5 and forcibly installing v5 into your Meteor dev bundle (by doing meteor npm install -g <package> is likely the cause of most of your problems. Some changes were necessary to work with the new package-lock.json files.
Meteor 1.6 will ship with npm@5, but it’s currently in beta. You can follow the pull-request for Meteor 1.6 if you’re interested in helping to test it out!
Also, depending on how old certain (non-core) packages and npms are, and personally, in general, I’d probably avoid doing mass dependency updates (like meteor npm updateandmeteor update --all-packages) on top of a major Meteor version upgrade. It’s usually safer to update single or small, closely-related subsets of npms/packages at a time and then commit those upgrades directly to your version control. This makes debugging quite a bit easier when it comes time to debug since each component was upgraded in isolation. It becomes a bit of the wild-west when everything gets upgraded at once!
Good to know @allenfuller – thanks! Mandrill probably uses STARTTLS, which will still provide secure transport, albeit after a brief insecure handshake period (with non-sensitive information). I’ll update my previous comment to avoid confusion.
