Patches & autoupdates

[wheresrhys]

I need to roll out an n-makefile fix to every user-facing app. With nbt it was as simple as nbt bottle patch && nbt rebuild --all --serves user-page. With n-makefile it's a commit to each repo.

BOOOO!

A few potential ideas

• config-vars pushes a script to ci which updates n.Makefile if present (possibly with some semver-aware logic)
• we create next-dev-tools now. One task of which is similar to nbt rebuild except it creates a new commit to master with an updated n.Makefile in each target repo

I'm still not sure how comfortable I am with commiting n.Makefile to the repo. Perhaps declaring an n.Makefile version in package.json and a) pushing an install script to CI via config-vars b) having a similar install script in next-dev-tools install is a better solution? @ironsidevsquincy @matthew-andrews

[matthew-andrews]

one thing i've been pondering is whether we should be locking everything down (shrinkwrap, fixed versions for bower, etc) and having something like greenkeeper do our updates so that we are in a bit more control over when things ship?

i.e. if we can get updates reduce to a single click (merge PR) would that be smooth enough to accept the hassle of a completely locked dependency tree?

[wheresrhys]

huddle it

[wheresrhys]

It would be great if we could scope shrinkwrapping to things we don't own

[matthew-andrews]

we can kind of do that by wrapping external deps in things like n-express and fixing its dependencies in package.json ^^