Was this intentionally not added to the command-line docs (help.txt)? I see it is not there, and that the checkbox in the PR description was left unchecked.

That seems unlikely @glasser; I would probably suspect the PR got merged and I forgot about it :/

That's pretty surprising @glasser. What happens if you run it again (w/ --all-packages)? If the same thing, does it help to run meteor update coffeescript etc?

I guess the reporting of "newer versions available" is wrong here, in the sense that they are available but not installable with the current constraints.

@glasser: Elaborating on what @tmeasday said, yes, it's an impossible constraint. Instead of meteor update <package>, you'll (generally) get more clear explanations of what the impossible constraint is by running:

meteor add <package>@<version>

For the first two, you'll likely get a clear answer of which packages are holding the update back (due to their own dependencies on older versions). In that regard, I think the textual-suggestion to meteor update <package-name> is entirely wrong and I'm not sure is (ever?) correct in that context.

Instead of helpful information on the problem though, you also might run into an MINISAT-out: Cannot enlarge memory arrays error (#7533) where essentially the constraint solver runs out of memory trying to help. Since 1.4.2.3 is in use here you could use my custom 1.4.2.3 release which doubles the memory limit available to minisat with --release abernix:[email protected]. That being said, it'll just be really slow at delivering you the harrowing news about the constraint issue which (from what I've seen so far) is thanks to an unpublished dependency.

In the case of coffeescript in this particular case, it's because 1.12.0_1 relies on [email protected] which is currently not released (only 6.14.0-beta.1 and 6.14.0-beta.0). I believe this is a side-effect of unpinned package versions getting published during beta cycles but not using the --release (or checkout) of the minimum version that they are intended to work on. I'm assuming this is the case as the releaseName in the packages.data.db DB (or troposphere, if my terminology is correct) is null, meaning [email protected]_1 may have been published from devel or release-1.4.3. That's speculation on my part, but @benjamn would know what the exact circumstances were at the time of publishing.