This is the comment thread for the Migrating to Meteor 1.6 article in the Meteor Guide.
The comment thread for each article appears at the very bottom of the page. Use this thread to post:
Or anything else related to this topic that people could find useful!
Ever since I upgraded to 1.6 underscore is undefined. .meteor/packages lists underscore@1.0.10 but when I connect to the server shell and try to use _.keys for example, it says undefined. Same happens in my code, breaking my site. Is there anything I need to do differently now with 1.6?
Interesting, I needed to import { _ } from 'underscore'; on server side where underscore is used.
@jamgold I believe this is all due to https://github.com/meteor/meteor/issues/9276, and I believe should only be a problem when using meteor shell, though please correct me if that’s incorrect. It’s something which will definitely have to be worked out!
While only applicable to Angular-Meteor projects running with shared node_modules, any recommendations on solving the Meteor 1.6 upgrade issue I reported in the angular category would be very helpful.
@abernix thanks for responding. Not only shell but all server code relying on underscore are affected. Including old atmosphere packages. Adding underscore to the package.json fixed the atmosphere packages.
This gave me a heads up that underscore is gone from global scope:
I view it as good news, now I can put a new version of lodash on my global scope as _.
I guess it is good news, just hope it’s not going to break a lot of things …
Just to be clear, 1.6 didn’t remove Underscore from the global scope in a way that would have taken it away from an application which had a proper dependency on it. If an application wishes to use _ in its own code, it should have already been depending on underscore in its .meteor/packages file, which declares dependencies for application code.
We have removed underscore as a dependency from many of Meteor’s internal packages though, which may have (by chance) provided _ to anyone who decided to use it without ensuring the dependency. It’s probably fair to say that if an application was relying on Meteor’s internal dependency on underscore in order to use _ within the its own code it was simply getting lucky and was in violation of an explicit dependency contract. As a similar example, if an application uses check(...), it should have check in its .meteor/packages file and not just rely on some other package providing that dependency on its behalf.
Either way, I suppose this is great baby steps to having less unexplained globals. I certainly understand how this might have subjected these _ variables to being used without explicit contracts to use them!
For as long as I can remember there’s been an explicit warning in the Meteor docs about underscore.
Currently, underscore is included in all projects, as the Meteor core depends on it.
_is available in the global namespace on both the client and the server even if you do not include this package. However if you do use underscore in your application, you should still add the package as we will remove the default underscore in the future.
(emphasis mine).
This seems to back up what I’m saying, but it sounds like we should make it even more clear now since the first half of the sentence is no longer always the case. Any chance for a docs PR on that @robfallows? (Or anyone!) 
You should be for your own sanity, and anyone who may work on the codebase, be importing every dependancy in a file.
If this breaks anything, its because you’re really not following what you surely know already to be best practice.