Should meteor CLI warn about "bad" packages?

[dandv]

Turns out meteor add summernote:summernote-compat doesn't even warn that that package has been set to unmigrated (Atmosphere doesn't either!).

Here's a flagged package: garrilla:d3 (and for good reason).

If I meteor add it, nothing will tell me that the package may not work correctly:

$ meteor add garrilla:d3
  added garrilla:d3 at version 3.4.13

garrilla:d3: A JavaScript visualization library for HTML and SVG. http://d3js.org

Is this OK? Shouldn't the meteor tool leverage the information that the community is contributing to Atmosphere, and warn about unmigrated ot flagged packages, offering a suggestion to search for alternatives?

Does the meteor tool perhaps not have access to Atmosphere data? (I can't imagine that's the case; at worst, it could scrape the package page). CC @tmeasday, @glasser, @ekatek.

[awatson1978]

Not necessarily a bad idea, but there are some unknowns with regard to stable-but-old packages getting flagged. Say there's a perfectly stable version of Bootstrap2 that hasn't been touched for a year. Should it get flagged? Should the CLI tool burp errors if someone is conservative or has business requirements asking them to build a Bootstrap2 app? This could be addressed in either part of the pipeline... with rules about how things get flagged; or with rules about how verbose the CLI is.

[raix]

@awatson1978 When scanning for good packages on npm I dont use packages where theres no activity - eg. if a npm havent been touched for 6month a bell rings, if its a new package less than 3 month old a bell rings again - all of these bells (getting closer to christmas). So an older package that is well used and well maintained, is better imho.

But what we should have was an editor review of the packages - maybe some packages can be added as "editors choice/favorite". This could result in a small article on how to use the packages etc.

So when publishing a package on should be able to add --review - I know that ideally packages should be free - but I still think that package writers should be able to earn money on writing good quality packages.

So some of the functionality from app stores could be applied here - for all to benefit. Not sure who should be paying for the review process - but I think it would help ensure quality? (just adding ideas here)