On continuous integration

Ideas:

reflects the status of the tests on last commit.

However the dependencies keep on changing (and as things go the dependencies will keep on increasing exponentially). Ideally a continuous integration system would look at the tree of dependencies (package.json) see which dependencies are fuzzy (this is the instructed approach ) and keep track for changes in those dependencies. Note that the change we are looking for there is version number changes in the published registry (npmjs).

If we see now the world after travis (or another travis-like service) implemented this feature, then as every component publishes a new revision that would trigger a re-evaluation of the tests of every (closure) dependent module/project that is linked with travis. (interestingly that would cause spiky usage.... on the other hand it may be less important to produce real time notifications to all the affected repo owners) A repo owner would the receive the notification that their repo failed passing as a result of  some change... in which case the have two options:

 - fix the problem

 - put a version restriction in their dependency file

The other interesting thing here is that ideally the person that wants to publish a new revision should be able to see the effect of their action before publishing. Ie for all dependent repos they should be able to run the tests - but having told travis to use their about to be published revision as if it were published.

The result should be then a list of all the repos that fail (and used to pass before).

The person could then do any of the following

 - Consider some of the failures as unintended effects/bugs of his rebision, esssentially views the vast # of repos as test suites for their library. In that case he proceeds to fix the bug

 - Consider some of the failures as an intended lack of backwards compatibility in which case the person can bot Submit issues to the affected repo owners that an upcoming release will cause their repos to fail. The bot could

  - just notify of the issue

  - suggest a pull request for changing the package.json

  - suggest a pull request that automatically fixes the problem if an automatic code update is feasible

and do all that ahead of the actual publishing of the new revision.
This would also give a user feedback to the repo owner how many of the users are willing to update their vs stick to the old release.

The world impact of all that is that code becomes aware of other code and bots are working to keep the overall system healthy... and more importantly a live deep dependency model becomes possible without forcing the freezing of dependent modules (which bring the problem of inconsistent modules being used by different libs and bugs not being fixed etc etc)